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The  purpose  of  the  study  was  to  design  a  missile  combat 
crew  scheduling  program  -for  use  by  the  scheduler  at  strate¬ 
gic  missile  wings.  Little  previous  research  has  been  done 
in  this  area. 

This  research  is  limited  in  scope  to  the  model  design, 
program  construction,  validation,  verification,  and  a  pre¬ 
liminary  analysis  of  the  schedules  produced  by  the  program. 
The  program  is  useful,  as  written,  to  the  the  wing  scheduler 
for  constructing  initial  monthly  operations  schedules.  The 
program  represents  one  part  of  a  Decision  Oriented  Manage¬ 
ment  System  for  missile  wings. 
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Abstrac  t 

A  missile  combat  crew  scheduling  program  was  developed 
using  the  SLAM  simulation  language.  The  program  schedules 
missile  combat  crew  members  -for  alerts,  training,  and  leave 
The  program  was  designed  to  build  monthly  schedules  -for  a 
three-squadron  strategic  missile  wing. 

A  performance  measure  was  developed  to  evaluate  alter¬ 
native  schedules  that  were  developed  by  the  program.  The 
measure  was  developed  by  using  Mu  1 t i -Cr i ter i a  Decision 
Theory  techniques  and  alternatives  were  compared  using  re¬ 
sponse  surface  methodology.  The  performance  measure  is 
general  in  nature  and  can  be  modified  to  apply  to  any  de¬ 
cision  maker. 

Analysis  was  conducted  to  determine  the  best  internal 
factor  settings  for  the  program  for  a  given  performance 
measure.  These  internal  factor  settings  are  used  to  de¬ 
termine  the  next  crew  selected  for  alert. 

Sensitivity  analyses  were  conducted  that  include  eval¬ 
uating  two  additional  performance  measures,  adding  an  as- 

t 

sumed  leave  distribution,  and  changing  the  structure  of  the 
crew  force. 

The  program  develops  feasible  monthly  schedules  that 
meet  the  performance  criteria.  The  internal  factors  were 
found  to  be  robust  across  al 1  three  performance  measures 


CHAPTER  I 


INTRODUCTION 


BACKGROUND 

The  scheduling  -for  missile  operations  crews  at  strategic 
missile  wings  <SMW>  is  done  manually  with  grease  pencils  and 
wall  boards.  It  is  a  time  consuming  process  that  requires 
the  -full  time  efforts  of  several  schedulers.  The  process  is 
inefficient  -for  several  reasons.  The  manual  manipulation  o-f 
scheduling  data  causes  errors,  trends  and  statistics  for 
scheduling  are  difficult  to  analyze  manually,  and  the  sched¬ 
uler  has  a  difficult  time  seeing  the  "big  picture.*  Eecause 
of  the  information  overload  of  the  manual  system,  opportuni¬ 
ties  for  improving  the  schedule  are  lost. 

There  are  no  measures  of  effectiveness  <MOEs>  that  tel  1 
the  schedulers  how  good  they  are  doing  their  jobs.  There 
are  also  no  criteria  for  dealing  with  conflicting  goals  that 
may  force  a  scheduler  to  choose  between  one  scheduling  al¬ 
ternative  and  another.  Even  the  goals  set  forth  for  the 
wing  schedule  are  vague  and  non-quan t i f i abl e .  Without  a 
clear  set  of  goals,  a  quantifiable  measure  of  effectiveness, 
and  a  method  of  choosing  between  scheduling  alternatives, 
there  is  no  incentive  to  produce  a  *good”  missile  operations 
schedule.  In  fact,  a  "good"  schedule  has  never  really  been 
defined,  and  that  is  part  of  the  problem. 


The  computerization  of  the  missile  scheduling  process 
could  reduce  these  problems  in  many  ways.  A  computerized 
system  that  is  designed  to  aid,  not  replace,  the  scheduler 
could  save  many  man-hours  in  producing  a  high  quality 
schedule.  The  computer  could  serve  as  a  data  base  -for 
scheduling  information.  After  the  scheduler  has  provided 
inputs  concerning  the  status  of  the  operational  force  and 
the  constraints  on  the  schedule  for  a  given  month,  the  com¬ 
puter  can  do  the  manual  work  of  filling  out  the  schedule  and 
checking  for  conflicting  entries.  If  a  conflict  exists  and 
the  scheduler  wishes,  the  computer  program  can  either  solve 
the  conflict  according  to  some  pre-established  rule  or  allow 
the  scheduler  to  solve  the  conflict  manually. 

Besides  computerizing  the  scheduling  process,  several 
other  areas  must  be  addressed.  Logical  measures  of  effec¬ 
tiveness  <MOEs)  must  be  devised.  These  MOEs  must  be  quan¬ 
tifiable  so  that  the  scheduler  can  tell  if  one  particular 
alternative  is  better  than  another.  Before  these  measures 
can  be  obtained,  specific  scheduling  goals  must  first  be 
developed.  This  type  of  information  is  obtained  by  using 
the  techniques  of  Mu  1 t i -Cr i ter i a  Decision  Theory  <MCDT> . 

Mi th  MCDT,  the  goals  and  MOEs  for  each  missile  wing  can  be 
developed  in  accordance  with  the  wishes  of  the  wing  com¬ 
mander.  Each  wing  may  have  different  goals  and  MOEs,  and 
each  wing  scheduler  would  incorporate  these  goals  and  MOEs 
to  improve  their  particular  schedule. 

The  computerized  schedule  could  also  improve  the 


scheduling  of  missile  combat  crew  members  (MCCMs)  by  in¬ 
suring  that  the  schedule  was  built  as  equitably  as  possible, 
taking  into  account  crew  member's  desires  to  the  maximum 
extent  possible. 

The  ability  of  a  missile  crew  scheduler  to  build  a  high 
quality  schedule  with  a  grease  pencil  and  a  wall  board  is 
limited.  The  two  major  problems  that  the  scheduler  en¬ 
counters  when  he  starts  to  build  the  schedule  are: 

a.  The  ambiguity  and  con-flicting  nature  o-f  the  sched¬ 
uling  objectives. 

b.  The  lack  o-f  selection  criteria  -for  choosing  among 
scheduling  alternatives  (Re-f  2). 

Berman  points  out  that,  ‘Even  if  the  computational  power 
were  available,  schedulers  still  lack  a  measurement  scheme 
that  provides  all  goals  in  a  structured  form  and  aids  in 
understanding  the  total  level  of  wing  performance.  They 
also  need  a  method  of  indicating  the  effect  of  tradeoffs 
among  conflicting  objectives  on  the  performance  measures. 
Without  such  tools  and  techniques,  the  ability  to  find  even 
near-optimal  solutions  is  lacking."  (Ref  7:83) 

Currently,  schedulers  can  create  one  feasible  schedule 
for  a  missile  operations  wing  per  month.  The  scheduler  has 
no  time  to  create  several  alternative  schedules  and  select 
the  best  schedule.  Additionally,  the  scheduler  does  not 
possess  a  means  of  comparing  alternative  schedules  to  de¬ 
termine  the  best  alternative.  A  computerized  scheduling 
system  would  allow  the  scheduler  to  create  alternative 


schedules  quickly.  If  some  criteria  for  judging  alter¬ 
natives  are  developed,  the  alternatives  could  be  examined 
and  the  best  schedule  selected. 


PROBLEM  STATEMENT 

An  efficient  method  to  allow  the  scheduler  to  create 
alternative  schedules  and  select  the  best  alternative  in  a 
timely  manner  does  not  exist. 

RESEARCH  QUESTIONS 

The  following  questions  are  what  this  research  intends 
to  answer: 

a.  Is  it  possible  to  develop  a  computer  model  to  build 
missile  combat  crew  <MCC>  schedules? 

b.  Is  it  possible  to  compare  alternative  schedules  in 
a  quantitative  manner? 


Q&IECTIVES 

The  objectives  of  this  research  effort  are  as  follows: 

a.  To  develop  a  computerized  scheduling  model  for  MCC 
scheduling,  that  allows  the  wing  scheduler  to  input 
data  and  build  a  number  of  alternative  schedules 
quickly  and  efficiently. 

Berman  suggests  a  good  reason  to  achieve  this  objective 
"If  we  could  mechanize  the  schedule  building  process,  even 
by  imitating  the  rules  used  by  schedulers,  we  could  examine 


many  schedules,  and  thus  depict  the  interrel  ations  o-f  var¬ 


iables  and  parameters.”  <Ref  7> 

b.  To  use  this  computer  model  to: 

1)  Analyze  alternative  schedules. 

2)  Determine  the  feasibility  of  using  the  model 
to  forecast  future  manning  requirements. 

SCOPE 

There  are  two  major  assumptions  used  in  this  research 
effort.  First,  alerts,  weapon  system  training,  Emergency 
War  Order  (EWO)  training,  Missile  Procedures  Trainer  <MPT> 
sessions,  and  leave  were  designed  to  be  scheduled  by  the 
model .  These  events  were  seen  as  capturing  the  essence  of 
the  schedule.  Other  events  such  as  evaluations,  hand  gun 
training,  and  physicals  could  be  added,  but  these  events  do 
not  significantly  effect  the  selection  of  the  best  alter¬ 
native  schedule. 

Second,  missile  combat  crew  members  were  scheduled  as 
crews,  not  on  an  individual  basis.  This  assumption  leads  to 
a  simplification  of  the  scheduling  problem,  but  there  are 
difficulties  with  this  approach.  These  difficulties  are  ex¬ 
amined  in  Chapter  IV  of  this  report. 


SYSTEM  STRUCTURE 

It  is  essential  to  look  at  the  structure  of  a  strategic 
missile  wing  <SMW>  in  depth  to  understand  the  task  that 


-faces  the  wing  scheduler. 

There  are  three  types  o-f  missile  combat  crews  (MCCs)  at 
an  SMW.  First,  there  are  the  crews  in  the  training  and 
evaluation  (DOT  and  DOM)  divisions  o-f  the  wing.  These  crews 
instruct  and  evaluate  the  rest  o-f  the  missile  crew  -force. 
Each  missile  -flight  consisting  o-f  three  to  six  MCCs  is  su¬ 
pervised  by  a  -flight  commander.  It  is  the  flight  command¬ 
er's  job  to  oversee  the  operation  of  the  flight.  He  takes 
care  of  details  such  as  administrative  paperwork  and  general 
supervision  of  the  MCCs  in  his  flight.  The  flight  commander 
is  also  expected  to  complete  a  certain  amount  of  "office 
duty"  every  month.  The  flight  commander  takes  care  of  prob¬ 
lems  and  administrative  details  that  occur  in  the  missile 
squadron  offices.  The  last  type  of  MCC  is  the  "line  crew". 
The  line  crew  is  the  basic  operations  resource  at  every  SMW. 

These  three  types  of  MCCs  also  perform  alert  duties  at 
three  different  alert  rates.  The  DOT/DOM  crews  normally 
have  two  alerts  per  month.  The  flight  commanders  have  four 
alerts  per  month  while  the  line  crews  usually  have  no  more 
than  eight  alerts  per  month.  The  eight  alert  per  month 
level  is  a  Strategic  Air  Command  (SAC)  guideline  for  the 
SMH.  This  guideline  can  be  exceeded  with  the  wing  command¬ 
er's  permission.  Obviously,  a  high  quality  schedule  is 
going  to  have  the  greatest  effect  on  the  line  crew.  The 
morale  of  the  line  crew  member  is  essential  to  improving  or 
maintaining  the  effectiveness  of  the  missile  combat  crew 


The  MCCs  perform  alerts  at  launch  control  centers 
<LCCs> .  At  the  341st  SMW,  Malmstrom  AFB,  Montana,  for 
example,  the  LCCs  are  located  anywhere  from  20  to  125  miles 
from  the  support  base.  The  distance  involved  to  and  from 
alerts  can  also  be  a  significant  factor  used  in  developing 
an  operations  schedule.  There  are  two  types  of  LCCs  at 
every  SMW.  The  primary  LCC  <PLCC>  can  be  manned  by  any 
qualified  MCC.  The  squadron  command  post  < SCP>/al ternate 
command  post  (ACP)  can  be  manned  only  by  SCP/ACP  qualified 
crew  members.  The  DOT/DO V  crews,  some  line  crews,  and  some 
flight  commanders  are  normally  ACP/SCP  qualified. 

There  are  three  or  four  squadrons  at  each  SMW.  Every 
squadron  has  five  LCCs  with  one  LCC  in  each  squadron  serving 
as  the  SCP.  In  addition,  one  SCP  serves  as  the  ACP  for  that 
wing.  This  means  that  there  are  a  total  of  15  to  28  LCCs  at 
each  wing,  with  two  to  three  SCPs  and  one  ACP.  There  are 
approximately  90  MCCs  at  a  three-squadron  missile  wing  when 
the  wing  is  fully  manned.  The  alert  load  for  each  of  the 
crew  types  depends  on  the  total  number  of  crews  and  the  num¬ 
ber  of  ACP/SCP  qualified  crews  at  each  wing.  These  are  the 
major  resources  that  a  wing  scheduler  has  to  use  when  he 
builds  an  operations  schedule. 

The  following  is  a  list  of  major  activities  that  the 
scheduler  must  assign  to  the  resources: 

a .  Alerts. 

b.  MCC  Training. 

DEmergency  War  Order  Training  (EWO)  . 
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2)  Codes  Training. 

3)  Weapon  System  Recurring  Training. 

c.  Missile  Procedures  Trainer  <MPT>  Session(s). 

d.  Leave. 

When  scheduling  MCC  classroom  training,  several  con¬ 
straints  are  usually  Kept  in  mind  by  the  scheduler.  First, 
the  number  of  class  days  is  kept  to  a  minimum.  This  is  done 
to  allow  instructors  more  time  to  perform  other  tasks  that 
they  are  responsible  for.  At  the  same  time,  the  class  size 
should  be  kept  to  a  manageable  level  to  allow  meaningful  and 
effective  training  for  the  MCCs.  These  two  goals  present 
the  scheduler  with  conflicting  alternatives.  How  the  sched¬ 
uler  resolves  that  conflict  has  an  effect  on  the  operations 
schedule.  Normally,  each  MCC  receives  this  training  on  a 
monthly  basis. 

MPT  sessions  are  classes  spent  in  a  simulator  practicing 
EWO  and  weapon  system  checklist  actions  to  keep  the  MCCs 
current  and  familiar  with  the  weapon  system.  The  amount  of 
MPT  time  each  MCCM  receives  is  set  by  the  Deputy  Commander 
for  Operations.  This  number  is  a  function  of  how  much  MPT 
time  is  available.  The  number  of  MPT  sessions  varies  from 
wing  to  wing.  If  an  MPT  is  broken  or  other  contingencies 
occur  then  the  number  of  MPT  sessions  per  MCC  changes.  Most 
MCCs  receive  one  or  two  sessions,  each  of  four  to  six  hours 
per  month.  SAC  regulations  require  that  each  MCC  receive  at 
least  one  MPT  session  every  six  months.  However,  the  number 
of  MPT  sessions  given  to  each  MCC  can  vary  widely  between 


Leave  is  usually  restricted  to  no  more  than  21  days  at  a 
time  -for  an  MCC.  This  is  a  -function  of  training  require¬ 
ments  and  manning  considerations  at  each  SM4.  Leave  is 
normally  taken  as  a  crew  (integral  leave),  but  there  are 
exceptions  to  this  policy.  The  number  of  crews  allowed  on 
leave  at  a  given  time  is  also  a  function  of  the  manning 
level  of  the  SMW.  These  are  the  operations  resources  and 
activities  that  the  scheduler  must  deal  with  every  time  a 
schedule  is  built. 

There  are  numerous  other  scheduled  activities  that  the 
scheduler  must  contend  with  on  a  daily  basis.  The  activi¬ 
ties  and  resources  listed  are  the  wing  schedulers  primary 
concern.  If  these  items  are  taken  care  of  the  other  activ¬ 
ities  are  minor  in  comparison. 

The  missile  operations  scheduler  takes  the  inputs  listed 
in  the  preceding  paragraphs  as  a  starting  point  for  building 
the  monthly  schedule.  These  inputs  are  used  by  the  sched¬ 
uler  in  some  heuristic  algorithm  that  creates  a  schedule. 

Additionally,  the  scheduler  has  the  following  con¬ 
straints,  as  a  minimum,  in  constructing  the  schedule: 

a.  All  launch  control  centers  (LCCs)  must  be  manned 
every  day. 

b.  All  training  must  be  administered  to  the  appropri¬ 
ate  crews. 

There  are  many  feasible  schedules  that  a  scheduler  can 
construct  within  these  constraints.  A  balance  between 


training  effectiveness,  resource  utilization,  and  morale 
must  be  maintained  to  build  a  schedule  that  works  and  is 


sati sf actory  to  everyone. 

One  major  problem  is  the  daily  schedule  changes  that 
occur  during  a  month  -for  one  reason  or  another.  Any  effort 
at  computerization  will  certainly  have  to  take  these  sched¬ 
ule  changes  into  account. 


PREVIOUS  RESEARCH  EFFORTS 

The  discussion  of  previous  research  e-f-forts  in  the  area 
of  scheduling  will  be  presented  in  two  parts.  The  first 
part  will  deal  with  the  types  of  scheduling  problems.  The 
solutions  attempted  for  these  problems  are  also  listed.  Th< 
second  part  will  deal  with  other  pertinent  information  re¬ 
lated  to  missile  combat  crew  scheduling  in  particular. 

SCHEDULING  PROBLEMS :  TYPES  AND  TECHNIQUES 

The  various  types  of  scheduling  problems  will  be  dis¬ 
cussed  first.  Problem  types  include:  job  shop  scheduling, 
maintenance  scheduling,  network  scheduling,  and  cyclical 
schedul ing. 

Job  shop  scheduling  involves  jobs  or  items  flowing 
through  a  machine  shop.  The  object  is  to  schedule  each  job 
for  the  proper  type  of  machine  at  the  proper  time  as  effi¬ 
ciently  as  possible.  The  jobs  may  have  to  be  done  in  a 
particular  order,  or  they  may  be  done  in  random  order, 


depending  on  the  job  shop.  Each  job  may  be  required  to 
visit  each  machine  in  the  job  shop  a  certain  number  of 
times,  or  it  may  only  visit  some  subset  of  the  machines  in 
the  shop.  Additionally,  there  may  be  several  types  o-f  jobs 
which  require  di-f-ferent  subsets  o-f  machines  or  different 
types  o-f  -flow  patterns.  Algorithms  to  solve  job  shop 
problems  usually  use  Integer  Linear  Programming  <ILP>  or 
heuristic  techniques.  These  algorithms  tend  to  be  created 
■for  specific  problems  rather  than  a  general  problem  type. 

The  literature  in  this  area  deals  with  finding  algorithms 
for  new,  specific  problems,  expanding  old  algorithms,  or 
exploring  how  different  algorithms  can  be  used  to  solve  the 
same  problem. 

Hosios  and  Rousseau  (Ref  18)  present  a  heuristic  algo¬ 
rithm  that  schedules  personnel  to  complete  a  set  of  activ¬ 
ities  every  scheduling  period.  The  activities  are  given  at 
various  times  and  locations.  The  algorithm  also  attempts  to 
minimize  the  number  of  personnel  at  every  location-activity- 
time  period.  The  algorithm  assumes  that  there  is  no  prefer¬ 
ence  by  the  personnel  about  the  order  of  completing  the 
activi ties. 

MCCs  must  also  be  scheduled  for  various  activities 
during  the  month.  The  order  of  the  activities  is  more  im¬ 
portant  in  the  missile  scheduling  problem,  however.  One 
objective  of  the  scheduling  program  is  to  spread  MCC  alerts 
throughout  the  month.  Hosios  and  Rousseau  do  not  consider 
this  problem.  All  activities  are  also  not  completed  by 


every  crew.  For  example,  only  SCP  qualified  crews  can 
perform  alerts  at  the  SCPs. 

Martel  (Ref  20)  looks  at  jobs  that  can  pre-empt  each 
other  and  that  have  specific  start  and  stop  times.  The 
problem  is  treated  as  one  of  entities  flowing  through  a 
network  with  the  objective  to  get  the  most  entities  through 
the  network  on  time. 

Pre-emption  is  not  a  capability  that  is  needed  in  sched¬ 
uling  MCCs.  The  scheduling  program  is  not  concerned  with 
finishing  a  project  in  an  optimal  amount  of  time.  The  pro¬ 
gram  is  concerned  with  allocating  scarce  resources  in  an 
efficient  fashion. 

New  (Ref  25)  discusses  various  dispatching  rules  for  the 
job  shop  and  how  they  effect  the  flow  of  jobs.  A  dispatch¬ 
ing  rule  is  a  method  for  ranking  jobs  waiting  to  begin  some 
process. 

The  idea  of  dispatching  rules  is  an  important  concept  in 
MCC  scheduling.  Deciding  on  the  next  crew  to  perform  alert 
is  a  problem  in  ranking  the  crews  that  are  waiting  to  be 
selected  for  alert.  New  examines  dispatching  rules  in  terms 
of  finding  a  rule  that  will  have  all  jobs  completed  in  the 
shortest  amount  of  time.  Once  again,  this  is  not  the  prob¬ 
lem  for  operations  scheduling.  The  problem  is  how  to  allo¬ 
cate  the  crews  in  the  best  possible  manner  to  complete  alert 
requirements. 

Maintenance  scheduling  problems  tend  to  cover  a  broad 
spectrum  of  maintenance  activities.  Some  problems  deal  with 


which  repair  crew  to  send  out  to  a  certain  location  at  a 


certain  time.  Other  problems  deal  with  scheduling  items 
through  a  maintenance  -facility  in  some  optimal  way  (similar 
to  a  job  shop  problem).  Still  other  problems  attempt  to 
deal  with  the  manpower  required  to  maintain  a  particular 
item  during  some  part  o-f  the  item/s  life  cycle.  Some  type 
of  1LP  is  usually  used  to  solve  these  problems,  and  a  wide 
variety  of  problems  can  fit  a  certain  program  structure. 
Several  problems  have  been  solved  using  the  simulation 
language  Q-GERT .  These  problems  dealt  with  scheduling  items 
through  a  maintenance  depot  facility  in  the  most  efficient 
way  (Ref  23) .  This  is  the  first  area  to  explore  the  use  of 
simulation  as  a  scheduling  technique.  There  has  been  a 
considerable  amount  of  1 i terature  on  maintenance  scheduling 
problems.  The  majority  of  this  literature  deals  with  the 
maintenance  of  power  generation  equipment. 

Yamayee  (Ref  32)  is  a  good  literature  review  of  research 
in  this  area.  This  report  concerns  the  scheduling  of  main¬ 
tenance  for  utility  company  power  generating  equipment.  The 
objective  of  the  scheduling  program  is  to  minimize  costs. 

To  accomplish  this  objective,  preventative  maintenance  is 
employed;  repairing  the  equipment  before  it  breaks.  There 
are  several  uncertainties  associated  with  a  long  term  sched¬ 
uling  program  in  this  area.  These  uncertainties  include: 

a.  Expected  power  load. 

b.  Fuel  prices. 

c .  Fuel  suppl ies. 
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d.  Maintenance  crew  availability. 

e.  Reliability  o-f  equipment  (Mean  time  between 
f  ai 1 ures) . 

Yamayee  presents  and  discusses  integer  programming,  dynamic 
programming,  and  heuristics  as  approaches  to  solving  this 
scheduling  problem. 

The  objective  o-f  maintenance  scheduling  is  to  minimize 
cost  by  either  reducing  manpower  requirements  or  reducing 
repair  costs.  To  do  this  requires  an  optimal  allocation  o-f 
repair  crews  and  money  to  the  equipment  being  maintained. 

The  objective  o-f  MCC  scheduling  is  to  allocate  crews  to 
alert  and  training  activities  in  an  optimal  -fashion.  Both 
maintenance  and  MCC  scheduling  deal  with  an  optimal  allo¬ 
cation  o-f  resources  to  activities.  Both  types  o-f  scheduling 
use  similar  methods  in  solving  the  problem  for  this  reason. 

Network  scheduling  involves  finding  the  critical  path 
through  a  series  of  activities  that  must  be  completed  in 
some  time  dependent  manner.  This  type  of  problem  is  nor¬ 
mally  concerned  with  construction  or  manufacturing  processes 
that  must  be  performed  in  a  sequence.  The  object  is  to 
identify  the  most  efficient  method  of  completing  the  activ¬ 
ities.  Another  objective  is  to  identify  where  efforts 
should  be  concentrated  to  improve  the  process  and  save  time. 
PERT  and  CPM  are  the  two  techniques  most  associated  with 
this  type  of  activity.  There  has  also  been  a  considerable 
amount  of  research  done  in  this  area.  Most  of  this  work  was 


done  about  10  years  ago 


Chiplunkar,  Mehndiratta,  and  Khanna  (Ref  9)  develop  a 
design  for  optimizing  the  routes  of  refuse  collection  trucks 


in  a  city.  A  heuristic  algorithm  is  used  to  analyze  the 
network . 

McGough  (Ref  21>  discusses  the  use  of  PERT/CPM  to  build 
activity  schedules  for  construction  projects. 

Crandall  and  Wool ery  <Ref  il)  and  Crandall  (Ref  10)  look 
at  stochastic  network  schedules.  These  types  of  schedules 
have  some  probabi 1 i ty  distribution  associated  with  project 
completion  times  and  the  criticality  of  activities.  This 
leads  to  a  set  of  probable  critical  paths.  Monte-Carlo 
simulation  was  used  to  generate  the  models.  Crandall  (Ref 
10)  compares  Monte-Carlo  simulation  and  PMET  in  generating 
schedules  with  stochastic  activities.  PMET  is  another  com¬ 
puter  algorithm  used  to  analyze  stochastic  networks. 

Cunto  (Ref  12)  describes  a  heuristic  algorithm  developed 
to  schedule  boats  for  sampling  oil  wells.  Each  boat  is 
assigned  a  specific  route  and  set  of  oil  wells  to  visit. 

The  oil  wells  are  sampled  at  specific  times  each  period. 

The  algorithm  has  improved  the  efficiency  of  this  sampling 
effort. 

Network  scheduling  is  similar  to  job  shop  scheduling  in 
that  it  seeks  to  optimize  the  flow  of  goods  or  activities 
through  a  process.  This  type  of  scheduling  deals  with  im¬ 
proving  the  time  it  takes  to  complete  the  network,  not  the 
amount  of  resources  it  takes  to  complete  a  task.  For  this 
reason  network  scheduling  is  not  helpful  in  building  an  MCC 


scheduling  program.  One  idea  from  network  scheduling  is 
important,  however.  MCCs  can  be  thought  of  as  entities 
flowing  through  a  network  at  a  constant  rate.  These  enti¬ 
ties  can  be  assigned  to  various  events.  This  concept  has 
applications  to  an  MCC  scheduling  program  as  is  shown  in 
Chapter  II. 

Cyclical  scheduling  involves  the  scheduling  of  people 
for  shift  work  or  a  schedule  of  on  and  off  days,  such  as 
nursing  schedules.  This  type  of  schedule  is  the  closest  to 
the  type  of  problem  that  involves  crew  scheduling.  Several 
good  articles  were  written  on  this  subject  in  the  mid- 
l?70's.  Warner  <Ref  31)  developed  a  nursing  schedule  that 
took  into  account  weekends  off,  work  stretches  (consecutive 
work  days),  single  days  off,  and  undesirable  work  patterns 
(back-to-back  shifts) . 

In  this  article,  Warner  also  addresses  the  need  for  a 
high  quality  schedule  to  keep  morale  high  and  to  improve 
working  conditions.  He  also  includes  a  method  of  weighting 
criteria  to  determine  the  "goodness*  of  a  schedule.  This 
technique  can  also  be  used  as  a  measure  of  optimality  for 
crew  schedules.  This  topic  will  be  discussed  in  detail  in 
Chapter  IV).  ILP  and  heuristics  were  the  main  techniques 
used  to  solve  these  types  of  problems.  The  majority  of  the 
literature  deals  with  different  ways  to  apply  these  tech¬ 
niques  to  slightly  different  variations  of  the  basic  prob- 
1  em. 

Mageath  (Ref  19)  and  Arthur  and  Ravindran  (Ref  3)  have 
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also  written  articles  on  the  nurse  scheduling  problem. 
Mageath  proposed  a  simple  heuristic  approach  after  rejecting 
a  mathematical  programming  one.  The  mathematical  program 
that  was  conceived  to  handle  the  problem  had  over  8800  vari¬ 
ables  and  400  constraints.  To  carry  out  such  an  analysis 
would  have  taken  more  computer  resources  than  the  hospital 
wished  to  provide. 

Arthur  and  Ravindran  proposed  a  goal  programming  ap¬ 
proach  to  the  nurse  scheduling  problem.  A  goal  program  in¬ 
corporates  several  goals  into  the  objective  function,  seek¬ 
ing  to  simultaneously  optimize  all  the  goals.  This  provides 
an  added  degree  of  flexibility  to  the  scheduling  program  in 
that  different  goals  can  be  substituted  into  the  program  if 
desired.  The  goal  program  is  used  to  determine  work  days, 
and  a  heuristic  (similar  to  Warner's  and  Mageath's)  is  used 
to  schedule  the  work  shifts  on  each  day. 

Bartholdi  <Ref  5)  looks  at  staff  scheduling  in  general. 
He  outlines  an  algorithm  that  will  minimize  the  work  force 
required  on  every  shift  and  give  two  consecutive  days  off 
every  week.  This  algorithm  is  limited  in  its  usefulness  to 
general  scheduling  problems. 

Warner's  use  of  a  set  of  weighted  criteria  is  very  sim¬ 
ilar  to  goal  programming.  A  set  of  weighted  measures  of 
effectiveness  is  generally  used  with  Mul ti-Cr i ter i a  Decision 
Theory  <MCDT> . 


The  work  of  these  authors  deals  with  one  aspect  of  MCC 
scheduling;  the  scheduling  of  alerts  is  a  cyclical  sched- 


uling  type  problem.  Both  heuristics  and  mathematical  pro¬ 
gramming  also  apply  to  MCC  scheduling,  as  they  apply  to 
cyclical  scheduling. 

However,  cyclical  scheduling  -falls  short  o-f  providing 
all  the  answers  -for  the  MCC  scheduling  problem.  First,  more 
than  one  type  o-f  activity  must  be  scheduled  for  MCCs,  not 
just  a  single  shift  per  day.  The  MCC  schedule  also  includes 
classroom  training  and  MPT  sessions.  This  can  be  thought  of 
as  three  different  cyclical  schedules  operating  simultane¬ 
ously.  Second,  leave  is  not  considered  in  the  cyclical 
scheduling  literature.  Bartholdi  is  the  most  ambitious  au¬ 
thor  in  this  area  by  suggesting  a  means  of  scheduling  two 
consecutive  days  off  for  personnel .  Leave  for  the  crew 
force  is  actually  some  type  of  probability  distribution  in¬ 
volving  the  starting  date,  the  duration,  and  the  number  of 
crews  taking  leave  at  the  same  time.  This  problem  exceeds 
the  ability  of  the  cyclical  scheduling  algorithms. 

The  difficulty  with  using  these  problem  types  as  a  guide 
to  MCC  scheduling  lies  in  the  techniques  used,  not  the  prob¬ 
lems  themselves. 

Scheduling  problems  are  normally  solved  by  using  Integer 
Linear  Programming  <ILP>,  Dynamic  Programming,  or  heuristics 
<Ref  32).  These  techniques  are  applied  to  the  different 
types  of  scheduling  problems. 

ILP  techniques  are  not  suitable  for  crew  scheduling  for 
the  following  reasons: 

a.  Number  of  constraints  involved, 


b.  Number  of  variables  involved, 

c.  Lack  of  flexibility  in  dealing  with  schedule 
changes,  and  changes  to  the  input  variables  and, 

d.  Inability  to  deal  with  the  stochastici  ty  o-f  the 
scheduling  process. 

Dynamic  programming  runs  into  similar  problems  dealing 
with  the  so  called  "Curse  of  Dimensionality"  (Ref  17:285) . 

Heuristics  offer  one  hope  for  the  scheduling  of  missile 
crews.  The  scheduler  currently  builds  the  schedule  by  using 
a  set  of  heuristics  that  he  has  developed.  The  use  of  sim¬ 
ulation  in  building  a  missile  schedule  would  take  this  set 
of  heuristics  and  automate  them.  This  would  give  the  sched¬ 
uler  a  method  of  comparing  alternative  schedules  and  would 
also  allow  analysis  to  be  performed  on  the  schedule. 

Several  additional  research  efforts  were  conducted  that 
should  be  discussed.  The  first  two  reports  deal  with  Stra¬ 
tegic  Air  Command  (SAC)  air  crew  scheduling  in  a  quantita¬ 
tive  fashion  (Ref  6,7).  These  reports,  by  Berman,  propose 
the  creation  of  a  Decision  Oriented  Scheduling  System  (DOSS) 
to  take  care  of  scheduling  shortcomings.  The  problems  of 
aircrew  scheduling  in  SAC  are  similar  to  missile  crew  sched¬ 
uling  problems. 

The  DOSS  objective  would  be  to  create  an  initial  sched¬ 
ule  and  identify  its  performance  level.  This  initial  sched¬ 
ule  would  then  be  changed  to  improve  its  performance  to  the 
desired  level.  According  to  Berman,  the  DOSS  should  be  able 
to  have  flexibility,  look  ahead,  and  handle  major  and  minor 


unforeseen  disruptions. 

Berman  suggests  that,  "While  there  are  no  known  optimi¬ 
zation  techniques,  sub-portions  of  the  scheduling  problem 
may  be  amenable  to  known  optimization  algorithms,  which 
should  be  used  when  possible  (Ref  £)."  Berman  also  goes  on 
to  say  that  Mul ti-Cri teria  Decision  Theory  (MCDT)  may  play 
part  in  the  optimization  process. 

A  third  report,  by  Angel  1 ,  was  written  specifically 
about  missile  crew  scheduling  (Ref  2).  This  report  spells 
out  a  process,  using  MCDT,  that  could  be  used  to  optimize  a 
crew  schedule.  In  addition,  Angel  1  discuss  scheduling  prob 
lees  pertinent  to  MCC  scheduling  and  a  systematic  approach 
for  coping  with  these  problems.  This  report  will  be  ref¬ 
erenced  in  other  portions  of  this  research  effort. 

Fallon  (Ref  15)  and  Hershauer  and  Ebert  (Ref  16)  deal 
with  an  area  of  study  called  Decision  Support  Systems. 

These  systems  are  computerized  models  that  use  cybernetic 
processes  to  mimic  decision  makers.  The  decision  makers 
attitudes  and  methods  of  making  decisions  (heuristics)  are 
input  into  a  computer  program  that  aids  the  decision  maker. 
The  idea  is  to  give  the  decision  maker  a  tool  that  consist¬ 
ently  supports  his  own  thought  processes.  This  idea  can  be 
applied  to  scheduling  in  particular.  Fallon  uses  these 
ideas  to  build  a  Decision  Oriented  Management  System  that 
helps  analyze  scheduling  decisions  at  SAC  B-52  wings. 

Decision  Support  Systems  are  designed  to  be  management 
analysis  tools  that  incorporate  scheduling  programs.  The 


scheduling  program  and  a  data  base  that  contains  information 
on  resources  are  combined  to  form  a  DOSS.  This  allows  the 


scheduler  to  recall  needed  information  from  the  data  base, 
consider  the  data  presented,  make  a  decision,  and  input  the 
decision  into  the  schedule.  The  schedule  is  updated  and  can 
be  judged  by  some  criteria  (a  measure  of  the  schedule's  per¬ 
formance)  to  determine  the  effect  of  the  decision  on  the 
quality  of  the  schedule.  In  this  way  schedules  can  be  built 
that  reflect  the  decision  maker's  desires  in  an  efficient 
manner . 

In  other  words,  the  scheduling  program  proposed  in  this 
research  effort  is  a  part  of  a  DOSS  that  could  effect  sched¬ 
uling  operations  at  the  strategic  missile  wing. 

Several  different  scheduling  techniques  are  being  ap¬ 
plied  to  several  different  types  of  problems  in  scheduling 
today.  Most  of  these  techniques  are,  unf ortunatel y ,  not 
what  is  needed  to  build  a  missile  crew  schedule.  The  works 
of  Berman  and  Angel  1  outline  what  is  needed  in  the  way  of  an 
effective  crew  scheduling  algorithm.  It  is  the  aim  of  this 
research  effort  to  carry  through  with  their  work  to  develop 
that  algorithm. 

METHQPQ1.Q{?Y 

This  research  effort  will  use  the  system  science  para¬ 
digm  as  a  general  method  of  accomplishing  the  research 
goals.  This  paradigm  is  set  forth  in  the  work  of  Scho- 
derbeck,  Schoderbeck,  and  Kef alas  <Ref  2?)  .  There  are  three 
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parts  to  the  paradigm: 

1)  Conceptualization, 

2)  Analysis  and  measurement,  and 

3)  Computerization. 

The  -following  paragraphs  will  discuss  each  part  in  more 
detai 1  . 

Conceptualization  involves  looking  at  the  problem  as  a 
system  that  interacts  with  its  environment.  The  idea  is  to 
try  to  capture  the  complex  interaction  o-f  the  system  and  its 
environment  as  a  series  o-f  models.  These  models  get  succes¬ 
sively  narrower  and  more  de-fined.  This  can  be  thought  o-f  as 
traveling  down  a  "cone  o-f  resolution"  from  the  top  (a  broad 
model)  to  a  point  where  the  model  is  specific  enough  to 
provide  the  type  of  understanding  desired  (Ref  29:297) .  The 
broad  model  is  conceptualized  as  a  set  of  inputs  that  are 
processed  to  provide  some  output.  The  inputs  are  brought 
into  the  system  from  the  environment  where  the  system  pro¬ 
cesses  them.  The  processed  inputs  are  then  returned  to  the 
environment  as  outputs.  The  object  of  the  model  is  not  to 
describe  every  detail  of  the  environment  and  the  system,  but 
to  model  the  important  aspects  of  both.  Once  this  broad 
model  is  built,  the  focus  of  the  model  is  narrowed  as  the 
researcher  tries  to  define  the  analysis  and  measurement  of 
the  critical  areas  of  the  model. 

Analysis  and  Measurement  tries  to  quantify  the  changes 
in  the  state  of  the  elements  of  the  model.  The  object  is  to 
gain  an  understanding  of  the  underlying  elements  of  the 


system.  Once  the  researcher  understands  the  process,  a 
model  is  built  that  describes  it.  Once  again,  the  model 
does  not  have  to  exactly  duplicate  the  system,  but  it  must 
duplicate  the  system  to  the  degree  that  it  achieves  the 
desired  objectives  o f  the  research.  In  this  part  of  the 
paradigm,  there  are  several  things  that  the  researcher  must 
dec i de : 

1)  The  language  in  which  the  results  of  the  model  will 
be  expressed  (LANGUAGE) . 

2)  Under  what  conditions  and  in  what  environments  the 
results  of  the  model  will  apply  (SPECIFICATION). 

3)  How  to  use  the  results  of  the  model  (STANDARDIZA¬ 
TION)  . 

4)  How  can  the  results  be  shown  to  be  “true",  and  how 
can  the  use  of  the  results  be  evaluated  (VERIFICA¬ 
TION  and  VALIDATION)  (Ref  29:301). 

Once  the  researcher  has  answered  these  questions  and  di¬ 
vided  the  model  into  its  elements,  the  computerization  part 
of  the  paradigm  can  begin.  The  output  of  analysis  and  meas¬ 
urement  should  be  in  a  form  that  can  be  programmed  on  a 
computer.  The  model  is  executed  by  the  computer  program, 
and  the  results  are  compared  with  the  system  and  the  con¬ 
ceptual  model.  If  the  results  are  not  what  is  expected,  the 
conceptual  model  is  either  re-examined  or  re-analyzed.  If 
the  results  are  what  is  expected,  the  model  can  be  used  to 
investigate  the  system. 

Using  this  general  model,  a  discussion  of  how  the  system 


science  paradigm  is  specifically  applied  to  this  research  is 
presented  in  the  following  paragraphs. 

The  computerized  scheduling  of  operations  at  a  ShW  can 
be  thought  of  as  a  series  of  inputs,  a  process,  and  an  out¬ 
put.  The  inputs  are  the  operational  resources  of  the  SMW. 
The  process  is  scheduling  (both  the  computerized  portion  and 
the  scheduler  developed  portion).  The  output  of  the  process 
is  the  operations  schedule  for  the  month,  along  with  accom¬ 
panying  statistics.  A  detailed  look  at  the  elements  of  the 
scheduling  system  and  their  environment  is  presented  in  Fig¬ 
ure  1-1.  This  model  determines  the  analysis  and  measure¬ 
ments  required  to  model  the  system. 

This  system  can  be  thought  of  as  taking  the  missile 
combat  crews  (MCCs)  and  allocating  them  to  various  jobs  as 
specified  by  the  heuristic  algorithm  used.  The  jobs  are  the 
activities  that  crew  members  must  be  scheduled  for  through¬ 
out  the  month.  These  activities  include:  alerts,  training, 
leave,  and  other  duties  that  preclude  alert  (such  as  meet¬ 
ings)  . 

The  simulation  of  the  system  takes  a  heuristic,  or  rule 
oriented,  approach.  This  heuristic  is  implemented  by  a 
discrete  event/network  simulation  model  that  handles  the 
inputs  to  the  system  in  a  controlled  fashion  to  generate  a 
schedule.  The  crews  are  viewed  as  entities  traveling 
through  the  network  to  different  events.  The  activities 
that  a  crew  must  perform  are  assigned  at  the  events.  A 
heuristic  algorithm  is  used  to  assign  the  crews  to  the 


activities  during  the  month.  This  model  structure  is  the 
same  as  the  system  structure  discussed  in  the  preceding 
paragraph.  The  model  and  the  system  can  be  thought  of  as 
having  a  combined  network/di screte  event  orientation. 

Considering  the  four  items  that  must  be  developed  in  the 


analysis  and  measurement  part  (Language,  Specification, 
Standardization,  and  Val i dat i on/Ver i f i cat i on) , 

a>  The  results  of  the  simulation  will  be  expressed  in 
the  form  of  a  matrix  representing  the  operations 
schedule  for  a  month. 

b)  The  results  will  apply  to  the  operations  portion  at 
an  SMW  as  long  as  the  correct  inputs  have  been  spec¬ 
ified.  This  program  will  deal  with  a  three-squadron 
wing,  but  the  model  can  be  changed  to  incorporate  a 
f our-squadron  wing. 

c>  The  results  will  be  used  to  generate  a  set  of  alter¬ 
native  schedules  that  can  be  compared.  The  best 
schedule,  as  judged  by  some  criteria,  can  be 
i mp 1 emen t  ed . 

d)  Verification  and  validation  will  be  covered  in  depth 
in  Chapter  III  of  this  research  effort.  The  output 
of  the  model  will  be  checked  against  the  conceptual 
model  to  insure  that  the  output  is  what  is  expected. 
Additionally,  the  model  output  will  be  compared  with 
actual  schedules  to  determine  if  the  model  produces 
an  accurate  operations  schedule. 

The  model  is  built  to  run  in  the  SLAM  simulation  lan¬ 
guage  on  a  Cyber  <750  or  74)  computer.  The  mathematical 
model  derived  in  the  analysis  and  measurement  part  is 
compatible  with  this  language.  A  discussion  of  why  this 
particular  model  was  chosen  is  appropriate  at  this  time. 

As  has  already  been  mentioned  in  the  background  portion 


of  this  chapter,  linear  programming  techniques  form  the 
majority  of  models  used  in  this  area.  But  there  are  several 
reasons  to  take  a  simulation  approach  rather  than  a  mathe¬ 
matical  approach  for  this  study.  A  linear  programming  model 
for  the  scheduling  problem  would  require  hundreds  of  con¬ 
straints  and  variables.  Many  aspects  of  scheduling  would  be 
difficult  to  put  into  a  constraint  format.  The  scheduling 
of  leave  is  an  example  of  this.  Every  leave  for  every  crew 
would  have  to  be  considered  a  constraint.  Any  change  in 
leave  would  change  the  entire  model,  because  the  constraints 
would  change.  In  addition,  any  change  to  the  input  varia¬ 
bles,  such  as  a  change  in  the  number  of  crews,  would  require 
a  complete  revision  of  the  program.  A  change  in  the  number 
of  crews  would  require  the  number  of  variables  and  the  con¬ 
straints  to  change.  This  makes  a  linear  programming  model 
large  and  inflexible  to  changes  in  the  input  variables. 
Linear  programming  problems  of  this  size  require  a  large 
amount  of  computer  time  to  run.  For  example,  one  computer¬ 
ized  model  using  an  IBM  370  computer  took  up  to  25  minutes 
of  run  time  to  develop  the  training  portion  of  a  schedule 
<Ref  8:46).  This  expense  is  difficult  to  justify  to  a 
decision  maker.  In  addition,  linear  programming  concepts 
are  difficult  to  explain. 

Ackoff  <Ref  1:372-375)  lists  over  a  dozen  reasons  why 
computer  simulation  should  be  used.  Several  of  these 
reasons  that  directly  apply  to  the  scheduling  program  are 
discussed  in  the  following  paragraphs. 


Simulation  requires  the  systematic  gathering  of  data 
about  a  system  and  its  environment.  This  leads  to  better 
understanding  of  the  system  by  the  designer,  a  better  un¬ 
derstanding  of  the  model  by  the  1 ayman < dec i si  on  maker),  and 
can  lead  to  insight  into  how  to  improve  the  process.  Pre¬ 
sent  schedules  will  be  examined  in  detail  to  determine  how 
schedules  are  constructed.  These  ideas  will  be  used  in 
developing  the  algorithms  used  in  the  scheduling  program. 

The  information  about  variable  relationships  is  easier 
to  modify.  Modifying  inputs  to  the  scheduling  program  does 
not  require  a  complete  modification  of  the  program  as  a 
change  to  the  constraints  and  variables  of  a  LP  program 
does. 

The  results  of  the  process  are  easily  explained  and 
conveyed  to  the  decision  maker.  The  results  of  the  sched¬ 
uling  program  are  placed  into  a  scheduling  matrix  by  using 
the  SLAM  language  itself.  A  separate  program  would  have  to 
be  built  to  do  this  for  an  LP  program. 

Separate  subsystems  of  the  process  can  be  analyzed,  and 
modified  if  desired.  The  various  modules  of  the  scheduling 
program  can  be  changed  without  changing  other  program  mod¬ 
ules.  This  is  not  true  of  an  LP  program.  Any  change  to  a 
constraint  or  a  variable  may  effect  the  entire  model. 

In  this  particular  case,  the  model  can  be  cheaper  to  run 
and  faster  to  load.  For  example,  changing  the  inputs  on  the 
scheduling  program  requires  less  time  than  re-programming  a 
change  to  an  LP  program. 


The  model  itself  can  be  used  to  sell  the  program  to  the 
decision  maker,  because  he  can  see  it  work.  The  scheduling 
program  can  be  shown  in  a  symbolic  form  that  the  decision 
maker  can  follow.  In  addition,  a  crew  can  be  traced  through 
the  scheduling  program  to  show  how  the  program  operates. 

This  is  not  possible  with  an  LP  model. 

The  total  system  is  investigated  in  a  simulation  ap¬ 
proach  reducing  the  chance  of  bias  effecting  the  results. 
Separate  LP  models  must  be  constructed  for  scheduling 
alerts,  training,  and  leave.  This  can  lead  to  bias,  because 
the  total  system  is  not  considered  as  a  whole.  The  entire 
system  is  modeled  at  once  in  the  scheduling  program.  <Ref 
1:372-375) 

In  addition,  there  has  been  little  research  done  in  this 
area  using  simulation  techniques.  This  research  could  lead 
to  a  better  understanding  of  the  role  of  simulation  in 
scheduling  support.  This  research  can  add  to  the  knowledge 
of  Decision  Oriented  Scheduling  Systems  (DOSS).  The  sched¬ 
uling  program  is  designed  to  fit  into  a  DOSS  network  for 
missile  scheduling.  The  intent  of  the  research  is  to  begin 
an  exploration  of  the  use  of  DOSS  in  this  area  of  decision 
making,  thus  providing  additional  information  on  DOSS.  For 
the  above  reasons  simulation  was  chosen  as  the  model  for 
this  project. 

Two  simulation  languages  were  available  to  the  authors 
for  this  research:  SLAM  and  Q-GERT.  Both  of  these  lan¬ 
guages  have  a  network  orientation  like  the  scheduling  sys- 


tern.  However,  SLAM  is  the  only  language  that  can  accomodate 
a  combined  network/di screte  event  orientation  that  is  nec¬ 


essary  in  the  scheduling  program.  SLAM  is  also  more  -flex¬ 
ible  than  Q-GERT  and  there  are  specific  subsystems  in  the 
model  that  are  not  feasible  to  program  in  Q-GERT.  Both  lan¬ 
guages  were  compatible  with  the  computer  resources  avail¬ 
able.  SLAM,  however,  is  more  widely  used.  Both  languages 
are  FORTRAN  based.  This  gives  program  transportability, 
because  FORTRAN  is  widely  used  in  the  military  and  civilian 
comruni ties. 

The  program  will  use  approximate  140,000  bytes  of 
memory.  This  amount  of  memory  is  not  compatible  with  a 
micro-computer,  but  the  program  can  be  executed  on  a  mini¬ 
computer  or  a  main  frame. 


SLAM 

SLAM  is  the  simulation  language  used  in  building  the 
scheduling  program.  Background  material  on  this  language 


will  aid  in  understanding  the  program.  An  excellent 
definition  of  SLAM  is  provided  by  A.  Alan  B.  Pritsker  in 


and  S 


SLAM,  a  new  Simulation  Language  for  Alternative 
Methods,  is  described  in  detail.  SLAM  is  an  ad¬ 
vanced  FORTRAN  based  language  that  allows  simula¬ 
tion  models  to  be  built  based  on  three  different 
world  views.  It  provides  network  symbols  for 
building  graphical  models  that  are  easily  trans¬ 
lated  into  input  statements  for  direct  computer 
processing.  It  contains  subprograms  that  support 
both  discrete  event  and  continuous  model  develop¬ 
ments,  and  specifies  the  organizational  structure 


-for  building  such  models.  By  combining  network, 
discrete  event,  and  continuous  modeling  capabili¬ 
ties,  SLAM  allows  the  systems  analyst  to  develop 
models  from  a  process-interaction,  next-event,  or 
activity  scanning  perspective.  The  interfaces 
between  the  modeling  approaches  are  explicitly 
defined  to  allow  new  conceptual  views  of  systems 
to  be  explored  <Ref  27:vii>. 

The  world  view  of  the  scheduling  program  is  a  combined 
network/discrete  event  orientation.  The  missile  operations 
crews  are  thought  of  as  transactions  traveling  through  a 
network  completing  various  events  at  different  times  during 
the  month.  FORTRAN  subroutines  are  inserted  into  the  SLAM 
program  to  direct  crews  to  their  next  event  or  activity. 

Once  the  model  has  been  built,  verified,  and  validated, 
a  method  can  be  developed  to  compare  alternative  schedules. 
Criteria  for  ranking  these  alternative  schedules  must  also 
be  developed.  These  criteria  are  applied  to  the  alterna¬ 
tives  to  select  the  best  schedule.  The  method  used  for 
comparing  the  alternatives  must  be  flexible  enough  to  allow 
a  variety  of  criteria.  This  requirement  is  needed  because 
every  decision  maker  will  have  unique  criteria  by  which  he 
will  judge  the  alternative  schedules.  The  different  cri¬ 
teria  will  effect  which  schedule  is  considered  the  best.  A 
method  of  comparing  alternative  schedules  is  presented  in 
Chapter  IV  of  this  report. 


Chapter  I  contains  an  overview  of  operational  scheduling 
at  strategic  missile  wings.  How  to  computerize  the  sched- 
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uling  system  to  improve  the  schedule  is  the  purpose  of  this 
research  effort.  The  chapter  included  a  review  of  the  re¬ 
sources  available  and  the  major  activities  that  must  be 
scheduled  by  the  wing  scheduler.  In  addition,  a  statement  of 
the  problem,  a  list  of  research  objectives,  a  section  on 
scope  and  limitations  of  the  research  effort,  and  background 
material,  including  previous  research  efforts  in  the  area  of 
scheduling  were  presented.  Following  these  sections  was  a 
discussion  of  the  general  and  applied  methodology  to  be  used 
in  the  research. 

ORDER  OF  PRESENTATION 

Chapter  II  will  present  a  detailed  look  at  the  concep¬ 
tual  model  used  in  building  the  computerized  scheduling  sys¬ 
tem.  This  model  is  broken  down  into  subsystems,  and  each 
subsystem  is  discussed  in  depth. 

Chapter  III  looks  at  model  validation  and  verification. 
Each  subsystem  is  checked  against  the  conceptual  model  to 
see  if  its  output  agrees  with  what  is  expected.  In  addi¬ 
tion,  a  schedule  produced  by  the  scheduling  program  is  com¬ 
pared  to  an  actual  schedule  from  the  44th  SMW. 

Chapter  IV  develops  an  experiment  investigating  a  method 
for  comparing  alternative  schedules.  MCDT  and  RSM  tech¬ 
niques  are  used  to  determine  the  best  scheduling  policies. 
The  experimental  results  are  presented  and  discussed.  Addi¬ 
tionally,  sensitivity  analysis  is  performed  on  the  model 
variables.  The  results  of  this  analysis  are  also  presented 


and  discussed 


Chapter  V  summarizes  the  research  e-f-fort  and  presents 
model  results.  Recommendations  -for  -further  research  are 
discussed,  and  some  concluding  remarks  about  the  research 
e-f-fort  are  presented. 

Two  appendices  are  included  with  the  report.  Appendix  A 
contains  the  computer  code  and  a  user's  guide  -for  the  sched¬ 
uling  program.  Appendix  B  contains  the  data  -for  the  analy¬ 
sis  presented  in  Chapter  IV. 


CHAPTER  II 


THE  MODEL 


INTRODUCTION 

A  broad  conceptual  model  -for  the  scheduling  program  was 
presented  in  Figure  I-*l.  A  narrower  and  more  defined  con¬ 
ceptual  model  is  present  in  Figure  1 1  —  1  of  this  chapter. 

This  model  is  then  broken  down  into  the  lowest  level  of  con¬ 
ceptual  models,  models  of  each  program  module.  These  out¬ 
lines  of  the  the  program  modules  give  a  structure  for  ana¬ 
lyzing  and  measuring  the  scheduling  system.  This  fulfills 
part  of  step  two  of  the  system  science  paradigm  presented  in 
Chapter  I.  The  remainder  of  this  step  is  discussed  in  Chap¬ 
ter  III  when  verification  and  validation  are  presented. 

These  concepts  presented  for  the  program  modules  can  be 
translated  into  computer  algorithms  for  the  computerization 
of  the  scheduling  model,  the  third  step  of  the  system 
science  paradigm. 

An  outline  of  the  scheduling  program  is  shown  in  Figure 
II-l.  This  outline  shows  tasks  that  must  be  accomplished  by 
the  scheduling  program  to  simulate  the  system.  This  outline 
also  applies  to  the  scheduling  system.  The  scheduler  first 
gathers  data  that  is  needed  to  build  the  schedule.  This 
data  includes:  the  crew  force  size  and  structure,  MPT 
availability,  the  number  and  size  of  classroom  training, 


Figure  1 1  —  1 .  Crew  Scheduling  Program  Modules 


leave,  and  other  duties.  The  scheduler  schedules  leave  and 
alerts  first.  These  two  activities  are  the  most  critical  in 
the  schedule  and  all  other  activities  are  scheduled  around 
them.  Classroom  training  and  MPT  sessions  are  assigned 
next.  Statistics  for  the  schedule  are  calculated  after  it 
is  completed.  Finally,  the  schedule  is  typed,  printed,  and 
distributed.  The  scheduling  program  operates  in  this  same 
manner . 

This  model  was  designed  as  a  set  of  modules  using  heur¬ 
istic  algorithms  to  build  a  missile  operations  schedule. 


s 


The  model  is  flexible  in  that  certain  variables  can  be 


changed  to  modify  the  schedule  that  is  built.  This  was  done 
to  allow  the  user  to  build  a  number  of  alternative  sched¬ 
ules.  An  experiment  is  presented  in  Chapter  IV  that  illu¬ 
strates  the  ability  of  the  model  to  construct  alternative 
missile  operations  schedules  and  judge  them  based  on  a  per¬ 
formance  measure  that  the  user  chooses.  The  following  is  a 
list  of  the  program  modules: 

a.  Initialization. 

b.  Leave/Alert  Scheduling. 

c.  Classroom  Training  Scheduling. 

d.  MPT  Scheduling. 

e.  Collecting  Statistics. 

f.  Output. 

The  following  paragraphs  will  explain  each  module  in  greater 
detail  discussing  the  objective,  reasoning,  and  algorithm 
used  for  each  module.  An  outline  of  each  module  is  also 
presented.  A  detailed  discussion  of  the  computer  code  with 
program  and  variable  listings  is  included  in  a  user's  guide 
contained  in  Appendix  A  of  this  report. 


INITIALIZATION 

The  objective  of  this  program  module  is  to  prepare  the 
program  to  build  an  operations  schedule.  The  outline  for 
the  initialization  module  is  shown  in  Figure  II-2. 

The  user  must  input  the  data  on  all  MCCs  into  the 


program.  This  data  includes: 


LCC  each  crew  is  assigned  to.  All  other  crews  are  placed  in 
the  EA  queue  and  are  eligible  for  alert. 


Next,  the  data  on  the  types  of  classroom  training  and 
the  days  of  the  month  that  this  training  can  be  given  are 
entered  into  the  program.  The  number  of  MPT  sessions  avail¬ 
able  on  each  day  must  also  be  input. 

Finally,  information  on  how  to  schedule  events  for  the 
crews  must  also  be  input  by  the  user.  This  information 
includes: 

a.  The  maximum  number  of  alerts  for  each  crew  type. 

b.  The  priority  rule  for  selecting  each  crew  type  from 
the  EA  queue. 

c.  The  number  of  days  in  the  month. 

d.  The  number  of  crews  in  the  crew  force. 

e.  The  minimum  and  maximum  number  of  students  in  each 
classroom  training  session. 

Next,  alerts  and  leave  are  scheduled  for  the  entire  crew 
force  for  the  month. 


LEAKE  AND  ALERT  SCHEDULING 

The  objective  of  this  program  module  is  to  schedule  all 
leaves  and  alerts  for  the  entire  month  for  the  crew  force. 
Any  alerts  that  cannot  be  scheduled  are  identified  and  a 
warning  message  is  printed.  The  concept  used  in  building 
the  code  was  to  have  the  off-going  crew  trigger  a  search  for 
a  new  crew  to  be  placed  on  alert  at  that  LCC.  The  problem 
with  this  concept  arises  when  there  are  no  crews  in  the  EA 


queue  to  be  sent  on  alert  on  that  day.  If  this  occurs  then 
no  more  alerts  will  be  scheduled  for  that  LCC  because  there 
are  no  more  off-going  crews.  The  program  recognizes  this 
problem  and  automatical  1 y  triggers  a  search  for  a  new  crew 
for  that  LCC  on  the  next  day.  Only  one  alert  must  then  be 
manually  scheduled  by  using  this  procedure.  The  program 
also  outputs  a  warning  message  that  no  crew  was  scheduled 
for  alert  at  that  LCC  on  that  particular  day. 

There  are  three  possible  activities  that  take  place 
after  a  crew  has  been  placed  on  alert  (See  Figure  II-3). 


Activity  one  places  the  crew  back  in  the  EA  queue  after  two 
days.  The  two  day  delay  represents  the  day  of  return  from 
alert  plus  24  hours  of  crew  rest. 

Every  crew  is  checked  immediately  after  completing  an 
alert  to  see  if  the  crew  has  leave  schedul ed  wi thin  the  next 
two  days.  If  leave  is  scheduled,  then  activity  two  is  taken 
and  that  crew  is  placed  in  leave  status.  The  crew  is  re¬ 
turned  to  the  EA  queue  after  the  crew's  leave  is  completed. 
The  crew  is  placed  on  leave  status  when  the  leave  period  is 
scheduled  to  begin.  If  leave  does  not  begin  immediately 
after  the  alert,  the  crew  is  eligible  to  be  selected  for 
classroom  training  or  an  MPT  session. 

Activity  three  places  the  crew  into  the  inactive  queue. 
This  queue  is  used  to  hold  crews  that  have  completed  their 
maximum  alerts  for  the  month.  The  crew  can  still  be  sched¬ 
uled  for  classroom  training  and  MPT  sessions  after  they  have 
been  placed  in  this  queue. 
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Figure  1 1-3.  The  Alert  and  Leave  Scheduling  Module 


All  three  activities  trigger  a  search  for  a  replacement 
crew  at  that  LCC.  This  process  is  repeated  for  all  15  LCCs 
every  day.  The  entire  SLAM  network  involves  this  program 
module.  This  network  and  a  description  of  it  is  contained 
in  the  user's  guide  in  Appendix  A. 

The  EA  queue  is  searched  every  day,  before  alerts  are 
assigned,  for  crews  going  on  leave  within  the  next  two  days. 
These  crews  are  removed  from  the  EA  queue  and  pi aced  on 
leave  status.  The  crews  are  returned  to  the  EA  queue  after 
their  leave  is  completed.  Crews  entering  the  inactive  queue 
are  checked  for  any  leave  requests  for  the  remaining  days  in 
the  month . 

Every  crew  can  have  up  to  three  separate  periods  of 
leave  specified  for  the  month.  The  number  of  leave  periods 
can  be  changed  with  minor  program  changes.  Although  the 
concept  is  called  leave,  this  time  off  represents  any  activ¬ 
ity  that  precludes  the  crew  from  performing  alert  duties. 


An  example  of  this  is  TDY,  or  upgrade  training.  The  leave 
scheduling  module  is  really  a  method  of  informing  the  pro¬ 
gram  that  any  given  crew  is  not  eligible  for  alert  for  cer¬ 
tain  periods  of  the  month. 

CLASSROOM  TRAINING 

The  objective  of  the  classroom  training  module  is  to 
schedule  all  crews  for  the  required  classroom  training  for 
the  month.  Conceptually,  the  program  tries  to  minimize  the 
number  of  classes  for  each  training  type,  and  limit  the 
number  of  crews  in  each  class.  These  two  objectives  contri¬ 
bute  to  training  effectiveness.  The  fewer  the  number  of 
classes  held,  the  more  time  instructors  can  spend  on  their 
other  duties.  The  fewer  crews  per  class,  the  more  individ¬ 
ual  attention  they  can  receive.  The  problem  is  that  these 
two  goals  conflict,  and  some  compromise  between  class  size 
and  number  of  classes  must  be  found. 

The  outline  for  the  classroom  training  module  is  shown 
in  Figure  1 1-4.  The  model  uses  a  two-pass  search  system  to 
schedule  classroom  training.  For  each  training  type,  the 
first  available  day  is  checked  to  see  if  there  are  enough 
crews  to  have  a  class.  The  range  of  class  sizes  can  be  set 
by  the  user.  The  initial  class  can  range  from  the  minimum 
value  set  by  the  user  to  80  percent  of  the  maximum  value. 

If  all  crews  have  not  been  scheduled  for  training  after  the 
first  pass  then  the  number  of  crews  allowed  in  each  class  is 
increased  to  the  maximum  value  set  by  the  user,  and  the 


Figure  II-4.  The  Classroom  Training  Module 


search  is  repeated  <the  second  pass).  The  first  pass  checks 
available  training  days  in  ascending  order  while  the  second 
pass  checks  training  days  in  descending  order .  This  heur¬ 
istic  evens  out  the  class  sizes  throughout  the  month  and 
increases  the  number  of  crews  scheduled  for  training.  Any 
crew  that  is  not  scheduled  for  training  after  the  second 
pass  is  flagged  by  a  warning  message.  Finally,  the  number 
of  classes  and  the  class  sizes  for  each  type  of  training  are 
printed.  This  routine  is  only  effective  at  scheduling  the 
entire  crew  force  for  an  activity.  Crews  should  be  sched¬ 
uled  for  individual  activities  using  the  leave  module.  This 
subroutine  does  find  a  compromise  between  the  class  size  and 
the  number  of  classes  presented.  The  values  can  be  changed 
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by  varying  the  class  size  range  or  number  of  available 
training  days. 

MPT  TRAINING 

The  objective  of  this  module  is  to  schedule  crews  for 
MPT  sessions.  The  number  of  MPT  sessions  for  each  crew  in  a 
month  is  determined  by  the  user.  Additionally,  the  number 
of  days  between  MPT  sessions  can  be  set.  Currently,  the 
model  is  set  to  schedule  every  crew  for  one  MPT  session  per 
month.  If  more  than  one  MPT  session  per  crew  is  set,  the 
user  must  supply  the  minimum  number  of  days  between  MPT  ses¬ 
sions  for  the  same  crew.  The  outline  for  the  MPT  training 
module  is  presented  in  Figure  I I -5. 

This  search  is  a  one  pass  system  that  is  executed  N 
times,  where  N  is  the  number  of  MPT  sessions  for  each  crew. 
The  program  checks  the  number  of  MPT  sessions  available 
every  day.  If  sessions  are  available,  crews  are  scheduled 
to  fill  the  slots.  The  crews  are  checked  in  descending 
order  by  crew  number.  A  crew  that  has  been  scheduled  for 
that  round  of  MPT  sessions  is  not  considered.  The  number  of 
MPT  sessions  available  is  decreased  for  a  given  day  as  crews 
are  assigned.  The  next  MPT  round  is  scheduled  in  the  same 
manner,  except  a  check  is  made  to  see  if  the  crew  had  an  MPT 
session  within  the  specified  minimum  number  of  days.  If 
this  is  the  case,  then  the  crew  is  not  assigned  and  the  next 
available  day  is  checked.  Any  crew  that  has  not  been  as¬ 
signed  to  the  appropriate  number  of  MPT  sessions  is  flagged 
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Figure  II-5.  The  MPT  Training  Module 


by  a  warning  message.  This  routine  is  similar  to  the 
classroom  training  module  in  that  it  can  only  be  used  to 
schedule  the  entire  crew  force  for  an  activity. 


COLLECT  STATISTICS 

The  objective  of  this  module  is  to  calculate  any  statis 
tics  desired  about  the  monthly  schedule.  The  statistics 
calculated  in  this  module  are  necessary  to  compare  alterna¬ 
tive  schedules.  This  information  is  used  in  the  experiment 
discussed  in  Chapter  1VJ. 

Information  is  extracted  from  the  completed  schedule. 
The  statistics  are  then  calculated  from  this  information. 
The  outline  for  the  statistics  module  is  shown  in  Figure 
1 1-6.  The  program  has  already  been  provided  with  a  crew 
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Figure  II-6.  The  Statistics  Module 


type  (line,  flight  commander,  or  DOT/DOV)  for  every  crew 
listed  in  the  schedule.  Only  line  crew  data  is  used  to 
compute  mean  and  variance  statistics  for  alert  rate, 
integral  alert  rate,  and  number  of  free  days.  It  is  the 
information  on  line  crews  that  is  important  in  determining 
statistics  for  the  schedule,  because  DOT/DOV  and  flight 
commander  crews  have  a  fixed  number  of  alerts  per  month. 


OUTPUT 

The  objective  of  the  output  module  is  to  present  the 
needed  information  to  the  user  in  a  readable  format.  The 
schedule  is  presented  in  a  coded  form.  For  example,  the 
value  1  on  a  given  day  indicates  that  a  crew  has  an  alert  at 
LCC  1.  A  complete  listing  of  the  codes  is  contained  in  the 
user's  guide  (Appendix  A).  The  monthly  statistics  printed 
about  the  schedule  include: 

a.  Crew  Number. 

b.  Number  of  alerts  for  each  crew. 

c.  Number  of  integral  alerts  for  each  crew. 

d.  The  total  number  of  free  days  for  each  crew. 


1 1  - 12 


e.  The  cumulative  line  crew  statistics 


The  outline  -for  the  output  module  is  presented  in  Figure 
1 1 -7.  In  addition,  sample  output  from  the  program  is  in¬ 
cluded  in  Figure  II-8  at  the  end  of  this  chapter. 


PROGRAM  STRUCTURE 

The  conceptual  modules  for  the  scheduling  program  were 
translated  into  computer  code  as  subroutines.  These  sub¬ 
routines  were  added  to  the  SLAM  executive  program  to  form 
the  total  scheduling  program.  The  following  paragraphs  are 
a  brief  introduction  to  each  program  subroutine.  A  complete 
listing  and  discussion  of  each  subroutine  is  contained  in 
the  user's  guide  in  Appendix  A  of  this  report.  The  follow¬ 
ing  is  a  discussion  of  the  scheduling  program  subroutines. 

The  initialization  subroutine  prepares  the  program  to 
build  a  schedule  and  gathers  the  data  needed  for  program 
execution.  The  event  subroutine  contains  the  logic  that 
switches  the  leave  and  alert  subroutines  on  and  off  as  re¬ 
quired.  The  leave  and  alert  subroutines  schedule  crews  for 
leave  and  alert  for  the  entire  month.  The  MPT  subroutine 
schedules  crews  for  MPT  sessions  while  the  classroom  train¬ 
ing  subroutine  schedules  classroom  training.  Finally,  the 
statistics  subroutine  calculates  the  statistics  needed  for 
schedule  evaluation  and  the  output  subroutine  prints  out  the 
completed  schedule  and  statistics.  Also,  warning  messages 
are  printed  by  the  respective  subroutine  for  any  activity 
not  scheduled.  For  example,  a  crew  missing  an  MPT  session 
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Figure  1 1 -7.  The  Output  Module 


would  cause  a  warning  message  to  be  printed  by  the  MPT 
subroutine. 


SUMMARY 

The  scheduling  program  was  designed  in  a  number  of 
modules.  These  modules  are  translated  into  subroutines  in 
the  computerized  model . 

The  model  is  designed  to  provide  a  monthly  missile  oper¬ 
ations  schedule  -for  a  strategic  missile  wing  with  three  op¬ 
erational  squadrons.  The  model  is  a  combined  discrete 
event/network  model  using  heuristic  algorithms  to  develop  a 
schedule.  Missile  operations  crews  can  be  thought  o-f  as 
transactions  -flowing  through  a  network  that  complete  events 
at  specified  times.  After  the  model  is  built,  the  next  step 
in  the  design  process  is  to  verify  and  validate  the  model 
design.  The  model's  ability  to  build  a  usable  operations 
schedule  is  tested  in  this  step.  Verification  and  valida¬ 
tion,  the  remaining  portions  of  step  two  of  the  system  sci¬ 
ence  paradigm,  are  covered  in  Chapter  III. 


Sample  Warning  Messages: 

Alert: 

crew  -file  empty  on  day  26  -for  lcc  12 
no  scp  crew  -for  scp  1  on  day  28 

Training: 

crew  35  not  scheduled  -for  XX  training 
crew  86  not  scheduled  for  mpt  2 


Training  Recap; 

for  XX  training  on  day  8,  10  crews  scheduled 


Schedule  Example: 

crew  scheduling  matrix 


1  2  3  4  . 

1  1  99  0  0  .  . 

2  9  XX  19?.. 


29  30  31 

11  9?  0 

0  6  99 


■ 

90 


0  XX  11  99  . 


99  0 


Statistics: 

individual!. 

ere*  1,  alerts  4,  integral  alerts  3,  free  days  14,  actual  maber  of  leave  days  0 


Cumulative  Line  Crew: 
number  of  alerts: 

mean  *  6.444  standard  deviation  =  .50156 

number  of  integral  alerts: 
mean  *  4.093  standard  deviation  =  .85271 

number  of  free  days: 

mean  *  14.38?  standard  deviation  =  .76273 


<NQTE:  XX  indicates  user  supplied  numeric  code.) 


Figure  1 1-8.  Sample  Scheduling  Program  Output 


CHAPTER  III 


VERIFICATION  AND  VALIDATION 


INTRODUCTION 

The  scheduling  program  must  be  veri-fied  and  validated 
before  it  can  be  used.  These  verification  and  validation 
processes  are  the  final  step  in  the  system  science  paradigm 
used  in  the  design.  The  verification  and  validation  proc¬ 
esses  are  iterative,  involving  a  re-conceptualization  and 
re-computerization  if  the  model  cannot  be  verified  and  vali¬ 
dated  in  its  present  form.  This  chapter  contains  background 
material  on  verification  and  validation  and  outlines  a  meth¬ 
odology  for  performing  these  procedures  for  the  scheduling 
program.  This  methodology  is  then  applied  to  the  model  and 
the  results  are  discussed. 

VERIFICATION 

Verification  is  the  process  of  checking  the  computer 
code  to  insure  that  the  program  executes  as  intended  (Ref 
27:10).  The  program  was  built  in  modules  to  simplify  the 
debugging  and  verification  efforts.  Each  module  was  checked 
separately  in  the  scheduling  program  by  printing  the  output 
of  the  module.  This  output  was  then  verified  to  insure  the 
program  had  functioned  properly  before  adding  the  next  mod¬ 
ule.  The  verification  process  is  discussed  for  each  module 


in  turn  in  the  -following  paragraphs. 

The  initialization  module  was  first  checked  to  insure 
that  the  user  inputs  were  placed  in  the  correct  storage  lo¬ 
cations  in  the  program.  This  included  both  crew  and  train¬ 
ing  information.  Secondly,  the  module  was  checked  for  its 
ability  to  place  crews  on  leave  status  correctly.  This  in¬ 
volved  insuring  that  the  starting  and  ending  dates  of  all 
leaves  scheduled  to  begin  on  the  first  day  of  the  month  were 
correct.  The  alert  and  leave  scheduling  module  schedules 
crews  for  leave  after  the  first  day  of  the  month.  Finally, 
the  module  was  checked  to  insure  that  the  15  crews  selected 
to  perform  alert  on  the  first  day  of  the  month  were  sched¬ 
uled  correctly.  The  alert  and  leave  scheduling  module  per¬ 
forms  this  function  after  the  first  day. 

The  alert  and  leave  scheduling  module  was  checked  next. 
First,  the  program's  ability  to  fill  alert  requirements  for 
the  month  was  checked.  Using  the  computed  schedule,  each 
day  was  checked  to  insure  a  crew  of  the  proper  type  (only 
ACP/SCP-qual if ied  crews  to  ACP/SCPs)  was  sent  to  each  launch 
control  center  <LCC> .  Next,  by  using  an  infeasible  crew 
force  size,  the  program-generated  warning  messages  for  un¬ 
filled  alerts  were  also  tested.  The  ability  of  the  module 
to  select  next  alert  crews  based  on  a  user  specified  per¬ 
centage  was  then  demonstrated.  Additionally,  the  schedule 
was  checked  to  verify  crews  were  placed  in  the  inactive 
queue  after  completing  their  maximum  number  of  alerts  for 


Finally,  the  leave  -function  o-f  the  alert  and  leave 
scheduling  module  was  verified.  Again,  using  the  computed 
schedule,  each  leave  request  was  compared  to  the  schedule  to 
insure  proper  beginning  and  ending  leave  dates.  The  EA 
queue  was  also  checked  to  insure  the  return  of  crews  follow¬ 
ing  leave  completion.  Proper  leave  updates  to  the  schedule 
were  also  checked  for  crews  entering  the  inactive  queue. 

The  classroom  training  module  was  checked  to  make  sure 
that  all  crews  were  scheduled  for  classroom  training  cor¬ 
rectly.  The  schedule  was  used  to  verify  each  crew  was  ei¬ 
ther  scheduled  for  each  type  of  training  or  was  reported  as 
not  being  scheduled  in  a  warning  message.  In  addition,  the 
ability  of  the  module  to  stay  within  the  given  class  size 
ranges  was  checked. 

The  MPT  training  module  was  verified  in  the  same  manner 
as  the  classroom  training  module.  In  addition,  the  ability 
to  separate  MPT  sessions  by  some  minimum  number  of  days  was 
checked  for  proper  operation. 

The  statistics  module  was  verified  by  hand  calculating 
the  individual  crew  and  cumulative  line  crew  statistics. 

Once  again  the  computed  schedule  was  used  to  gather  the  nec¬ 
essary  information. 

The  operation  of  the  output  module  was  checked  through¬ 
out  the  verification  process.  As  each  module  was  verified, 
the  printed  information  concerning  that  module  was  checked 
for  errors. 
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Validation  is  the  process  of  insuring  that  the  sched¬ 
uling  model  accurately  reflects  the  scheduling  system  to  the 
degree  desired.  The  ability  of  the  scheduling  program  to 
build  a  feasible  operations  schedule  is  the  accuracy  needed. 
The  output  from  the  scheduling  model  is  validated  by  compar¬ 
ing  it  to  existing  operations  schedules  from  an  operational 
SMW.  The  inputs  from  these  manually  generated  schedules  are 
used  as  inputs  for  the  scheduling  program.  Validation  was 
accomplished  by  taking  a  missile  combat  crew  schedule  and 
duplicating  it.  This  was  done  by  determining  the  inputs  to 
the  scheduling  program  based  on  the  actual  schedule.  The 
two  schedules  were  then  compared  using  criteria  discussed  in 
the  following  paragraphs.  If  the  schedules  did  not  agree 
then  the  scheduling  program  was  adjusted  and  executed  again 
until  it  closely  matched  the  existing  schedule. 

The  following  output  information  is  compared  to  the  data 
from  the  manually  generated  schedules: 

a.  Is  the  schedule  feasible?  (does  it  meet  all  con¬ 
straints)  . 

b.  The  alert  rate  and  variance. 

c.  The  average  number  of  free  days. 

d.  The  number  of  class  days  for  each  type  of  classroom 
training. 

e.  The  class  size  and  variance  for  each  type  of  class¬ 
room  training. 

f.  The  average  number  of  HPT  sessions  for  the  crew 
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g.  The  integral  alert  rate  and  variance. 

This  information  is  important  because  it  captures  the 
essence  of  what  an  operations  schedule  should  do.  The 
schedule  must  be  feasible,  or  it  is  worthless.  To  be  fea¬ 
sible  the  schedule  must  fill  the  alert  requirements  which 
means  that  there  will  be  an  alert  rate  and  an  average  number 
of  free  days  for  the  crew  force.  The  class  size,  variance 
and  number  of  classes  is  a  measure  of  the  schedule's  ability 
to  efficiently  allocate  the  crews  to  classroom  training 
sessions.  The  average  number  of  MPT  sessions  is  also  a 
measure  of  this  ability.  The  integral  alert  rate  is  a 
measure  of  the  scheduling  program's  ability  to  adjust  to  an 
existing  schedule.  Can  the  program  be  tuned  to  develop  a 
given  integral  alert  rate,  is  the  question  addressed  by  this 
criterion.  Significant  differences  between  the  scheduling 
model  and  the  manually  generated  schedules  are  discussed  in 
the  next  section. 


SCHEDULE  SELECTION 

A  schedule  from  Ellsworth  AFB  was  selected  to  validate 
the  scheduling  program.  This  schedule  was  selected  from 
among  schedules  from  Malmstrom,  F.E.  Warren,  and  Whiteman 
AFBs.  The  schedule  from  Ellsworth  AFB  was  selected  because 
it  typifies  a  schedule  from  a  three-squadron  strategic  mis¬ 
sile  wing  (SMW) .  The  schedule  from  Malmstrom  AFB  was  not 
chosen  because  it  contained  a  large  number  of  crew  changes 

1 1 1-3 


spread  throughout  the  month.  A  crew  change  is  a  crew  split 
where  the  crew  partners  are  reassigned  to  other  crews  or 
other  duties.  There  were  over  40  such  changes  in  the  sched¬ 
ule  -from  Malmstrom  AFB.  The  scheduling  program  is  not  de¬ 
signed  to  handle  this  type  of  problem.  Every  SMW  will  have 
some  crew  changes  in  a  month.  If  these  crew  changes  are 
made  at  the  beginning  of  the  month,  for  example,  the  changes 
would  pose  no  problem  for  the  program.  (A  methodology  for 
dealing  with  crew  changes  is  discussed  later  in  this  chap¬ 
ter.)  An  integral  crew  structure  was  assumed  as  one  of  the 
limitations  of  this  research  effort.  With  this  number  of 
crew  changes,  the  scheduling  program  would  have  to  run  on  a 
person  by  person  not  a  crew  basis.  A  problem  significantly 
more  difficult  to  solve  than  the  one  for  crew  scheduling. 

The  schedule  from  F.E.  Warren  was  not  selected  because 
this  SMW  has  four  squadrons.  The  program  is  designed  for  a 
three-squadron  SMW.  A  four  squadron  scheduling  program  can 
be  built  with  modifications  to  the  existing  program.  These 
modifications  would  be  major  in  terms  of  the  amount  of  code 
changed,  but  not  in  terms  of  the  conceptual  model.  Whiteman 
AFB  schedules  were  not  selected,  because  the  Emergency 
Rocket  Communications  System  (ERCS)  is  located  at  this  base. 
The  schedule  here  requires  special  rules  and  procedures  to 
schedule  crew  members  associated  with  the  ERCS  system.  The 
program  should  be  easy  to  modify  to  consider  these  rules. 
With  these  problems  in  mind,  the  Ellsworth  schedule  was  se¬ 
lected  as  the  best  choice  for  validation. 


The  problem  of  split  crews  still  had  to  be  addressed 


with  the  Ellsworth  schedule,  but  on  a  smaller  scale. 


Ellsworth,  like  other  ShWs,  has  several  reserve  crew  members 


<RSCMs> .  An  RSCM  is  one  who  is  currently  without  a  crew 


partner.  How  to  input  the  RSCM  into  the  scheduling  program 


was  the  initial  problem  faced  in  the  validation  process. 


There  are  two  types  of  RSCMs  encountered  in  the  Ellsworth 


schedule.  An  RSCM  that  is  crewed  with  a  permanent  partner 


some  time  during  the  month  is  the  first  type  of  RSCM. 


This  crew  was  treated  as  being  unavailable  for  alert  (on 


leave)  until  the  crew  was  formed.  The  second  type  of  RSCM 


is  a  crew  member  that  is  not  crewed  with  any  one  crew  member 


for  the  entire  month.  This  type  of  RSCM  was  ignored  in  the 


initial  validation  computer  run.  This  means  that  several 


crew  members  capable  of  performing  alert  were  not  included 


in  the  schedule.  The  consequence  of  ignoring  these  crew 


members  will  be  discussed  in  the  initial  validation  run 


resul ts. 


INPUT  PREPARATION 


The  next  problem  is  to  determine  the  scheduling  inputs 


for  the  program  by  looking  at  the  manually  generated  sched¬ 


ule.  The  exact  inputs  to  this  schedule  are  unknown  and  had 


to  be  estimated.  The  following  variables  were  set  based  on 


the  manually  generated  schedule  for  the  first  validation 


a.  The  15  crews  for  alert  on  the  first  day. 
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b.  All  leave  requests  -for  the  crews. 

c.  The  actual  training  days  used  for  classroom  train¬ 
ing  in  the  Ellsworth  schedule. 

d.  The  actual  number  of  MPT  slots  in  the  Ellsworth 
schedul e. 

The  Ellsworth  schedule  was  set  to  give  all  line  crews  and 
flight  commander  crews  approximately  one  MPT  session  per 
month.  Only  24  percent  of  DOT/DOV  crews,  however,  are 
scheduled  for  an  MPT  session  in  the  Ellsworth  schedule.  The 
scheduling  program  cannot  set  one  MPT  rate  for  one  type  of 
crew  and  a  different  rate  for  another  crew  type,  therefore, 
an  MPT  rate  of  one  MPT  per  crew  for  all  crews  was  set.  The 
ability  to  set  different  MPT  rates  for  different  crew  types 
is  not  needed.  If  one  crew  type  is  to  receive  a  different 
number  of  MPT  sessions,  these  sessions  can  be  manually 
reconci 1 ed. 

Scheduled  duties  and  meetings  are  treated  as  leave  for 
the  crew  even  if  only  one  crew  partner  is  scheduled  for  the 
meeting.  This  same  policy  is  adopted  for  only  one  crew 
partner  taking  leave.  The  crew  partner  not  on  leave  can  be 
scheduled  for  other  duties  manually.  Integral  leave  is  the 
policy  at  ShWs,  but  there  are  exceptions. 

In  addition,  the  class  size  range  is  set  between  six  and 
fifteen  crews  per  class.  The  maximum  number  of  alerts  for 
line,  flight  commander,  and  DOT/DOV  crews  is  eight,  four, 
and  two  respectively. 

There  are  also  five  internal  percentages  in  the  sched- 
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uling  program  that  effect  the  selection  of  crews  for  the 
next  alert.  The  first  three  percentages  affect  the  next 
alert  at  non-SCP  LCCs  while  the  last  two  affect  SCPs.  These 
are: 

1.  The  percentage  of  time  that  a  DOT/DOV  crew  is 
selected  for  a  non-SCP  alert. 

2.  The  percentage  of  time  that  a  flight  commander 
crew  is  selected  for  alert  at  their  home  LCC. 

3.  The  percentage  of  time  a  crew  is  selected  for 
alert  at  their  home  LCC. 

4.  The  percentage  of  time  a  DOT/DOV  crew  is  selected 
for  alert  at  an  SCP. 

5.  The  percentage  of  time  an  SCP  crew  is  selected  for 
alert  at  their  home  LCC. 

VALIDATION  RIM  RESULTS 

Table  III-l  contains  the  results  for  the  first  vali¬ 
dation  run  of  the  scheduling  program  compared  to  the 
Ellsworth  schedule.  The  schedules  are  compared  using  the 
procedure  discussed  in  the  validation  section  of  this 
chapter . 

The  alert  rates  from  the  two  schedules  are  within  three 
percent  of  one  another,  but  the  scheduling  program  has  a 
higher  variance.  The  10  alerts  performed  by  the  reserve 
crew  members,  who  were  never  crewed  with  a  permanent  crew 
partner,  is  the  probable  reason  for  the  difference  in  alert 
rates.  These  crews  were  never  considered  in  the  initial 
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First  Run  Results 


Ellsworth  Schedule 

ALERTS 

Mean  6.29 

Variance  1.08 

INTEGRAL 

ALERTS 

Mean  3 . 94 

Variance  1.67 

FREE  DAYS 

Mean  12.98 

Variance  11.11 

MPT 

Mean  0.74 

CLASS  SIZE 
Class  1 


Mean  9 . 30 

Variance  9.12 

Class  2 

Mean  9.4 

Variance  5.82 

CLASS 

NUMBER 

Class  1  10 

Class  2  10 


Scheduling  Program 


6.48 

1.56 


2.79 

2.79 

12.65 

24.01 

0.93 


12.86 

2.48 

11.86 

8.48 


7 

7 


run,  decreasing  the  size  of  the  crew  force.  A  smaller  crew 


force  will  have  a  higher  alert  rate  and  a  lower  number  of 
free  days.  Changing  the  crew  force  to  include  the  reserve 
crew  members  should  decrease  the  alert  and  increase  the 
number  of  free  days  for  the  automated  schedule. 

The  integral  alert  rate  was  higher  and  the  variance 
lower  for  the  Ellsworth  schedule  compared  to  the  scheduling 
program.  The  integral  alert  rate  for  the  program  was  set  at 
50  percent,  while  the  Ellsworth  schedule's  integral  alert 
rate  was  actually  63  percent.  Setting  the  integral  alert 
rate  higher  in  the  program  should  increase  this  statistic. 

A  thorough  study  of  the  integral  alert  rate  is  presented  in 
the  experiment  discussed  in  Chapter  IV. 

The  program  did  not  schedule  six  crews  for  an  MRT  ses¬ 
sion.  These  crews  can  be  substituted  manually  for  DOT/DOV 
crews  in  a  short  period  of  time.  This  is  not  a  serious  sit¬ 
uation.  An  increase  in  MPT  availability  on  a  certain  day  or 
an  increase  in  the  total  number  of  MPT  slots  should  solve 
the  problem. 

The  class  size  ranges  for  both  schedules  are  comparable. 
The  scheduling  program  used  a  class  size  range  of  between 
six  and  fifteen  crews  per  class.  The  Ellsworth  schedule 
class  size  ranges  were  from  six  to  sixteen  crews  and  five  to 
thirteen  crews  for  type  one  and  type  two  training,  respec¬ 
tively.  The  scheduling  program  uses  fewer  days  for  training 
and  has  a  better  overall  variance  because  of  the  heuristics 
employed  in  the  program  to  minimize  class  days.  Seven  crews 
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could  not  be  scheduled  for  type  two  training  by  the  program. 
A  large  amount  of  leave  by  these  crews  is  the  reason  for 
this.  This  is  not  an  unusual  situation  at  SMWs.  Several 
crews  must  be  given  individual  classroom  training  every 
month  because  of  leave  considerations.  These  crews  can  be 
manually  scheduled  for  type  two  training  by  using  one  of  the 
following  methods: 

a.  Schedule  the  crew  for  individual  crew  training  at 
some  time  during  the  month. 

b.  Schedule  the  crew  on  a  training  day  that  increases 
the  class  size  past  the  maximum  value  of  15  crews 
per  class. 

c.  Switch  the  day  for  type  one  training  so  that  type 
two  training  can  be  given  on  that  day. 

The  scheduling  program  is  given  eight  days  as  possible 
training  days  for  classroom  training.  The  program  used 
seven  of  these  days.  The  Ellsworth  schedule  was  originally 
thought  to  have  eight  training  days  scheduled,  but  actually 
had  ten  days  of  classroom  training.  The  scheduling  program 
was  given  fewer  days  in  which  to  schedule  training  and  used 
fewer  days  with  a  more  constant  class  size. 

Because  of  the  differences  in  the  two  schedules  it  was 
decided  to  perform  another  validation  run  with  the  following 
two  changes.  First,  increase  the  percenatge  of  time  a 
DOT/DOV  crew  is  selected  for  an  SCP  alert.  This  change 
should  increase  the  alert  rate  for  DOT/DOV  crews  to  their 
maximum  of  two  (Three  DOT/DOV  crews  performed  only  one  alert 


in  validation  run  one.).  Also,  two  crews  should  be  added  to 
the  crew  force  to  simulate  the  unaccounted  for  RSCMs  of  the 


first  validation  run.  Since  the  Ellsworth  RSCMs  performed 
ten  alerts,  each  added  crew  in  the  scheduling  program  was 
given  leave  for  part  of  the  month  to  decrease  their  alerts 
to  ten  also. 

The  integral  alert  rate  percentage  was  not  changed  in 
the  program  to  see  what  effect  the  other  changes  would  have 
on  the  schedule.  Table  1 1 1-2  presents  the  data  from  the 
second  validation  run  compared  to  the  Ellsworth  schedule. 

The  changes  to  the  program  inputs  resulted  in  several 
significant  changes  in  the  schedule.  First,  the  alert  rate 
and  variance  in  the  alert  rate  decreased  while  the  integral 
alert  rate  remained  the  same.  This  increased  the  average 


number  of  free  days  as  expected.  The  addition  of  the  two 
crews  caused  the  changes  in  the  schedule. 

The  second  validation  run  showed  that  the  scheduling 
program  is  capable  of  developing  a  feasible  schedule  given 
realistic  inputs.  The  model  can  accurately  reflect  a  typi¬ 
cal  missile  operations  schedule  and,  therefore,  appears  val¬ 
id  for  its  intended  use.  One  additional  validation  run  was 
performed  to  see  the  difference  that  occurs  if  the  integral 
alert  rate  is  increased  from  59  to  63  percent  and  19  train¬ 
ing  days  are  available  for  scheduling  classroom  training. 
This  validation  run  was  made  to  see  if  the  scheduling  pro¬ 
gram  could  build  a  better  schedule  than  the  manually  gener¬ 
ated  schedule  in  terms  of  the  validation  criteria.  The 
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Table  1 1 1-2.  Second  Run  Results 


Ellsworth  Schedule 

Schedulino  Proqram 

ALERTS 

Mean 

6.29 

6.23 

Variance 

1.68 

1.30 

INTEGRAL 

ALERTS 

Mean 

3.94 

2.82 

Variance 

1.67 

2.69 

FREE  DAYS 

Mean 

12.98 

13.21 

Variance 

11.11 

15.37 

Mean 

0.74 

0.93 

CLASS  SIZE 

Class  1 

Mean 

9.30 

13.  14 

Variance 

9.  12 

4.48 

Class  2 

Mean 

9.4 

11.86 

Variance 

5.82 

13.  14 

CLASS 

NUMBER 

Class  1 

10 

7 

Class  2 

10 

7 
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results  are  listed  in  Table  1 1 1-3. 

Changing  the  integral  alert  percentage  in  the  program 
-from  58  to  43  percent  increased  the  integral  alert  rate  to 
57  percent  as  compared  to  43  percent  -for  the  Ellsworth 
schedule.  This  is  a  significant  increase  and  demonstrates 
the  usefulness  of  such  a  variable  in  the  program. 

Increasing  the  number  of  days  available  for  each  type  of 
classroom  training  also  caused  a  significant  change.  The 
number  of  days  when  classroom  training  was  scheduled  in¬ 
creased  to  eight,  and  only  three  crews  were  not  scheduled 
for  classroom  training.  All  of  these  crews  can  be  manually 
scheduled  for  training. 

Both  reserve  crew  members  were  checked  to  insure  that 
another  crew  member  was  available  to  perform  alerts  with 
them  when  their  alerts  were  scheduled  during  the  month. 

This  check  was  made  manually,  and  the  crew  partners  were  as¬ 
signed  manually.  This  process  does  not  take  a  significant 
amount  of  time  to  perform. 

The  changes  to  the  inputs  for  the  scheduling  program 
further  improve  the  schedule.  These  changes  show  that  the 
schedule  can  be  tuned  to  achieve  a  desired  scheduling  ob¬ 
jective.  This  process  will  be  studied  in  detail  in  the 
experiment  presented  in  Chapter  IV. 

Several  problems  were  noted  in  the  validation  process. 
The  technique  of  adding  crews  to  simulate  the  existence  of 
reserve  crew  members  is  a  useful  one.  This  technique  can  be 
used  whenever  a  reserve  crew  member  is  available  in  the 


Table  1 1 1-3.  Third  Run  Results 


Iljsworth  Schedule 


Scheduling  Program 


ALERTS 


Mean 


6.29 


6.23 


Variance 


1.88 


1.35 


INTEGRAL 

ALERTS 


Mean 


3.94 


3.52 


Variance 


1.67 


2.99 


Mean 


12.98 


13. 18 


Variance 


11.11 


15.  13 


Mean 


0.74 


0.92 


Class  1 


Mean 


9.30 


11.39 


Variance 


9.  12 


9.57 


Class  2 


Mean 


11.25 


Variance 


5.82 


5.64 


CLASS 

NWBER 


Class  1 


Class  2 
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scheduling  program.  The  program  has  a  definite  handicap  in 
dealing  with  split  crews,  however.  In  order  for  the  sched¬ 
uler  to  use  the  program  effectively,  crew  changes  will  have 
to  be  kept  to  a  minimum.  Ideally,  crew  changes  would  be 
made  once  a  month  (preferably  at  the  beginning  of  the  month) 
and  input  to  the  initial  data  inserted  into  the  program. 

This  technique  can  be  applied  to  crew  changes,  but  it  is  of 
limited  use  in  making  a  large  number  of  them. 

Another  problem  area  is  the  number  of  scheduled  duties 
precluding  alert  that  are  scheduled.  The  three  periods  of 
leave  set  in  the  scheduling  program  are  sometimes  not  enough 
to  schedule  all  activities  for  the  crew  force.  The  number 
of  leave  periods  should  be  increased  to  at  least  four  or 
five  periods  per  crew. 

Chapter  IV  will  use  the  verified  and  validated  sched¬ 
uling  program  to  analyze  program  variables  and  to  present  a 
procedure  for  comparing  the  worth  of  alternative  schedules. 
Such  a  procedure  is  valuable  to  a  scheduler  because  he  can 
generate  several  schedules  for  use  in  a  given  month.  His 
selection  can  be  based  on  the  use  of  the  procedure  outlined 
in  the  next  chapter.  This  procedure  is  one  of  many  such 
methods  that  can  be  used.  The  discussion  in  Chapter  IV 
provides  an  example  of  the  type  of  research  that  can  be  done 
with  the  scheduling  program. 


CHAPTER  IV 


EXPERIMENTAL  DESIGN  AND  APPLICATION 


INTRODUCTION 

Now  that  a  program  has  been  built  that  schedules  missile 
operations  crews,  the  model  can  be  used  to  accomplish  the 
objectives  of  this  research  effort.  Those  objectives  are 
the  development  of  high  quality  missile  operations  sched¬ 
ules,  and  the  performance  of  analysis  that  supports  this 
development.  The  problem  that  now  faces  any  prospective 
user  of  the  program  is  the  definition  of  a  "high  quality" 
schedule.  The  solution  to  this  problem  cannot  be  unique. 
Every  decision  maker  will  have  a  slightly  different  opinion 
about  what  constitutes  a  good  schedule.  What  the  scheduling 
program  will  allow  a  decision  maker  to  do,  if  the  program  is 
combined  with  some  performance  measure,  is  to  build  a  sched¬ 
ule  that  meets  the  specifications  of  a  given  decision  maker. 
The  objective  of  the  experiment  discussed  in  this  chapter  is 
to  provide  a  decision  maker  with  a  method  of  determining  the 
quality  of  a  schedule.  This  method  does  not  guarantee  that 
a  schedule  produced  by  the  program  is  an  "optimal"  schedule. 
Rather  the  method  introduced  in  this  chapter  provides  the 
decision  maker  with  a  method  of  comparing  alternative  sched¬ 
ules  and  deciding  which  of  these  alternatives  he  prefers. 

Two  things  must  be  designed  to  perform  the  experiment: 


a  method  of  scoring  alternative  schedules,  and  a  method  to 
use  -for  -finding  the  best  a)  ternative. 

The  performance  measure  used  in  this  experiment  is  de¬ 
veloped  by  using  a  technique  -from  the  field  of  Multi-Cri¬ 
teria  Decision  Theory  <MCDT> .  It  must  be  emphasized  that 
the  performance  measure  derived  here  is  not  the  only  one 
that  can  be  built.  There  are  many  different  techniques  that 
can  be  used,  and  this  is  an  example  of  one  of  these  tech¬ 
niques.  Any  performance  measure  can  be  used  in  this  experi¬ 
mental  design  if  the  scheduling  program  can  compute  the  nec¬ 
essary  data  for  the  performance  measure.  The  particular 
technique  demonstrated  in  this  experiment  is  worth  assess¬ 
ment.  This  MCDT  technique  is  simple  to  use  and  provides  a 
numerical  score  for  each  alternative. 

Using  an  MCDT  technique  is  applicable  to  this  problem 
because  there  are  multiple  objectives.  Mul ti-Cri ter ia 
Decision  Theory  is  a  set  of  analysis  techniques  that  are 
used  to  simultaneously  meet  several  objectives. 

After  the  performance  measure  has  been  developed,  an 
experimental  design  must  be  built  for  testing  the  various 
alternatives  and  finding  the  best  schedule.  Response  sur¬ 
face  methodology  was  used  as  the  design,  and  this  process  is 
discussed  after  the  section  on  worth  assessment. 

A  discussion  of  the  experiment  and  the  results  of  the 


experiment  follows.  This  discussion  will  include  a  step  by 


step  analysis  of  the  experimental  procedure  and  the  building 
of  the  performance  measure.  Finally,  sensitivity  analyses 


will  be  performed  on  the  results  of  the  experiment  to  see 
how  sensitive  the  alternative  selected  is  to  changing  fac¬ 
tors  in  the  schedul ing  model  and  to  changing  performance 
measures. 

WORTH  ASSESSMENT 

Worth  assessment  is  used  to  compare  alternative  sched¬ 
ules.  This  technique  develops  a  measure  of  performance  for 
a  given  schedule.  The  scheduling  program  can  then  build  a 
number  of  alternative  schedules  that  can  be  evaluated  in  a 
structured  manner  to  find  the  best  alternative.  A  set  of 
objectives  that  describes  the  performance  of  a  schedule  must 
be  developed  first.  From  these  objectives,  a  performance 
measure  can  be  built. 

Worth  assessment  is  the  MCDT  technique  used  in  this 
research  effort,  because  the  technique  aids  in  determining 
what  the  decision  maker  feels  is  important  about  the  sched¬ 
ule.  Worth  assessment  is  being  used  as  an  example  of  one 
type  of  performance  measure.  The  technique  of  worth  assess¬ 
ment  can  be  adapted  to  any  decision  maker,  to  develop  a  per¬ 
formance  measure  specifically  tailored  for  him.  A  discus¬ 
sion  of  the  worth' assessment  technique  follows. 

Worth  assessment,  as  outlined  by  DeWispelare  (Ref  13> , 
has  six  steps: 

1.  List  the  overall  objectives  or  attributes. 

2.  Construct  a  hierarchy  of  these  performance  criteria. 

3.  Select  physical  measures  for  the  lowest  level  attri- 


butes 


4.  De-fine  the  relationship  between  the  attributes  and 
the  physical  measures. 

5.  Establish  the  relative  importance  of  each  attribute. 

6.  Adjust  the  weights  of  the  attributes  to  increase 
the  decision  maker's  confidence  in  their  accuracy. 

Worth  assessment  assumes  that  the  attributes  are  "worth 
independent".  Worth  independence  is  defined  as  the  decision 
maker  being  willing  to  get  more  of  one  attribute  for  less  of 
another  with  no  change  in  the  decision  maker's  satisfaction. 
The  satisfaction  that  a  DM  feels  for  a  particular  attribute 
value  is  the  worth  of  that  attribute  at  that  value.  The  re¬ 
lationship  between  the  worth  of  an  attribute  and  the  minimum 
and  maximum  values  of  that  attribute  is  assumed  to  be  linear 
in  the  procedure. 

Building  an  objectives  hierarchy  is  the  first  step  in 
the  Worth  Assessment  procedure.  This  hierarchy  is  con¬ 
structed  starting  with  an  overall  objective  for  the  sched¬ 
ule.  This  primary  objective  is  broken  down  into  a  series  of 
sub-objectives  with  the  lowest  level  sub-objectives,  or  at¬ 
tributes,  being  measureable.  These  lowest  level  attributes 
will  be  used  to  score  schedules  that  are  developed.  This 
objectives  hierarchy  must  agree  with  the  decision  maker's 
concept  of  what  attributes  are  important  to  the  schedule. 

If  the  objectives  hierarchy  does  not  agree  with  the  decision 
maker's  ideas  then  the  hierarchy  is  re-designed  until  it 
agrees  with  the  desires  of  the  decision  maker. 
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Angel  1  (Ref  2)  discusses  the  need  for  the  development  of 
such  an  objectives  hierarchy.  The  hierarchy  that  Angel  1 
derives  in  his  report  serves  the  same  purpose  as  the  one  in 
this  report;  to  provide  a  measure  o-f  the  worth  o-f  a  sched¬ 
ule  and  to  allow  comparison  o-f  alternative  schedules. 

An  objectives  hierarchy  -for  the  scheduling  program  is 
presented  in  Figure  IV-i.  This  hierarchy  is  similar  to 
Angel  1 's  (Re-f  2:27),  but  the  hierarchy  addressed  here  is 
-focused  speci-f ical  1  y  on  the  issues  developed  by  the  sched¬ 
uling  program,  not  simply  on  scheduling  in  general. 

The  six  measureabl  e  attributes  developed  -for  the  sched¬ 
uling  program  are:  MPT  time,  classroom  e-f -f ec t iveness , 
maximum  alerts,  di-f-ference  in  alert  rates,  -free  days,  and 
integral  alert  rate.  These  attributes  are  measureabl e  in 
that  each  one  has  a  measure  o-f  effectiveness  (MOE)  associ¬ 
ated  with  it.  The  MOE  is  some  physical  measure  of  each 
attribute.  The  measure  can  be  related  to  how  well  the  at¬ 
tribute  has  been  fulfilled  by  a  particular  alternate  sched¬ 
ule.  The  MOEs  for  each  attribute  are  discussed  in  the  fol¬ 
lowing  paragraphs. 

MPT  time  will  be  measured  by  the  number  of  MPT  sessions 
that  each  crew  receives  during  the  month.  The  decision 
makers  at  a  strategic  missile  wing  are  usually  very  inter¬ 
ested  in  this  measure,  and,  generally,  have  some  amount  of 
MPT  time  that  they  desire  to  see  each  crew  receive.  The 
number  of  MPT  sessions  was  chosen  as  the  MOE  for  this  attr-i- 
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Figure  IV- 1.  Objectives  Hierarchy  -for  Operations  Schedule 

Classroom  effectiveness  will  be  judged  by  the  variance 
in  the  class  sizes  of  the  different  classroom  training 
types.  Initially,  the  MOE  for  this  attribute  was  the  number 
of  training  days  for  each  training  type  divided  by  the  total 
number  of  training  days  available.  It  was  discovered  in  the 
validation  portion  of  the  research  that  the  number  of  train¬ 
ing  days  used  by  the  program  varied  only  slightly  making 
this  a  poor  MOE  for  this  attribute.  Although  the  quality  of 
training  is  effected  by  many  factors,  class  size  is  the  only 
factor  effected  by  the  scheduling  program.  A  constant  class 
size  certainly  increases  the  probability  that  all  crews  are 
being  trained  to  the  same  level  of  knowledge  and  perform¬ 
ance,  therefore  variance  in  class  size  was  selected  as  the 
MOE  for  this  attribute. 

The  average  alert  rate  and  variance  in  alert  rate  are 


chosen  as  MOEs  for  maximum  alerts  and  di-fference  in  alert 
rates  respective!  y.  These  two  measures  appear  to  -fit  the 
attributes  wel 1 . 

The  average  number  o-f  -free  days,  and  the  percent  of  in¬ 
tegral  alerts  performed  were  chosen  as  MOEs  for  the  last  two 
attributes  for  the  same  reason. 

There  are  several  considerations  taken  into  account  when 
determining  the  relationship  between  the  physical  measure 
and  the  attribute.  The  following  is  a  list  of  the  consider¬ 
ations,  suggested  by  DeWispelare: 

a.  Is  the  measure  continuous  or  discrete? 

b.  Does  the  measure  possess  upper  and  lower  bounds? 

c.  What  values  of  the  measure  can  be  associated  with 
a  worth  of  zero  and  one? 

d.  Does  a  higher  value  of  the  measure  show  a  greater 
or  lesser  worth? 

The  objective  of  these  questions  is  to  determine  the 
relationship  between  the  MOE  and  the  worth  of  the  attribute. 
In  other  words,  a  method  of  converting  the  MOE  value  to  a 
worth  value  is  defined  by  these  questions. 

The  relationship  between  MOE  and  worth  values  is  assumed 
to  be  linear  in  the  worth  assessment  procedure.  Once  the 
quesions  outlined  above  have  been  answered,  converting  an 
MOE  value  to  a  worth  value  is  a  matter  of  determining  the 
maximum  and  minimum  values  for  the  MOE,  determining  the  MOE 
value  for  a  particular  schedule,  and  performing  linear 
interpolation  to  detemine  the  worth  value  for  the  particular 


attribute  in  question.  The  worth  value  o-f  an  attribute  is 


assumed  to  be  a  value  between  zero  and  one.  Table  IV- 1  sum¬ 
marizes  the  relationship  o-f  MOE  values  to  worth  values  -for 
the  scheduling  program  objectives  hierarchy. 

Many  o-f  the  values  in  Table  IV- 1  must  be  computed  based 
on  the  size  and  structure  o-f  the  crew  -force.  An  example  o-f 
the  worth  assessment  procedure  will  be  shown  to  illustrate 
how  these  values  can  be  computed. 

The  next  step  in  the  worth  assessment  process  is  to 
establish  the  relative  weights  o-f  the  objectives  and  attri¬ 
butes  in  the  hierarchy.  To  do  this  the  attributes  are  di¬ 
vided  into  groups  with  the  relative  importance  o-f  the  attri¬ 
butes  within  each  group  being  established  -first.  The  objec¬ 
tives  and  attributes  -for  the  scheduling  program  are  divided 
into  -five  groups:  the  primary  objective,  the  three  sub¬ 
objectives  beneath  the  primary  objective,  and  the  six  lower 
level  attributes  which  are  divided  into  three  groups  o-f  two 
attributes  each. 

DeMispelare  suggests  one  method  of  establishing  the 
relative  importance  of  the  attributes  within  each  group. 

His  method  is  to  have  the  decision  maker  rank  the  attributes 
on  a  scale  from  one  to  one  thousand.  The  reason  for  using 
such  a  large  scale  is  that  some  decision  makers  have  diffi¬ 
culty  trying  to  distinguish  between  attributes  on  a  smaller 
scale  (zero  to  one,  for  example).  It  is  important  to  note 
that  the  weights  of  the  attributes  within  each  group  must 
sum  to  1000  to  allow  this  method  to  work.  The  rank  of  each 
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attribute  is  divided  by  1000  after  the  decision  maker  has 
completed  his  ordering  of  all  groups  to  provide  attribute 
weights  with  values  between  zero  and  one. 

Once  the  relative  importance  of  each  attribute  within 
the  group  has  been  determined  the  relative  weight  of  any 
attribute  compared  to  the  entire  performance  measure  can  be 
found.  The  weight  of  any  attribute  is  determined  by  multi¬ 
plying  the  relative  weight  of  the  attribute  by  the  relative 
weights  of  all  objectives  that  it  is  a  sub-objective  of.  An 
example  of  this  process  should  make  this  statement  clear. 

Assume  that  a  decision  maker  has  been  asked  to  establish 
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the  relative  importance  of  the  attributes  and  objectives 
listed  in  Figure  IV-1.  These  attributes  are  -first  divided 
into  -five  groups  composed  o-f  the  -following  attributes: 

a.  Group  1 — Maintain  a  Credible  Deterrent  Capability. 

b.  Group  2 — Training  E-f-fectiveness,  Resource  Utiliza¬ 
tion,  and  Moral e. 

c.  Group  3 — MPT  time  and  Classroom  E-f-fectiveness. 

d.  Group  4 — Maximum  alerts  and  di-f-ference  in  alert 
rates. 

e.  Group  5 — Free  days  and  integral  alerts. 

The  relative  importance  o-f  the  attributes  within  each  group 
are  determined  next. 

Maintaining  a  credible  deterrent  capability  is  given  a 
rank  of  1080  because  it  is  the  only  objective  in  this  group. 
Assume  that  the  ranks  o-f  the  three  sub-objectives  in  group 
two  are  given  ranks  o-f  400,  400,  and  200  respectively.  Ad¬ 
ditionally,  assume  that  the  following  ranks  are  given  to  the 
six  lower  level  attributes  in  groups  three,  four,  and  five: 

a.  Group  3:  MPT  time — 600 

Classroom  Effectiveness — 400 

b.  Group  4:  Maximum  alerts — 500 

Difference  in  alert  rates — 500 

c.  Group  5:  Free  Days — 600 

Integral  Alerts — 400 

Note  that  the  ranking  of  each  attribute  must  be  divided  by 
1000  to  find  the  relative  weight.  This  is  shown  in  Figure 
IV-2. 
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Figure  IV-2.  Attribute  Weights  -for  Objectives  Hierarchy 


To  determine  the  weight  of  an  attribute  in  comparison  to 
the  entire  performance  measure,  the  following  method  is  il¬ 
lustrated  using  the  attribute  of  maximum  alerts.  The  rela¬ 
tive  weight  of  the  maximum  alerts  attribute  (0.5)  is  multi¬ 
plied  by  the  relative  weight  of  the  resource  utilization 
sub-objective  <0.4>  (maximum  alerts  is  a  sub-objective  of 
resource  utilization)  and  by  the  relative  weight  of  the  pri¬ 
mary  objective  (1.0)  (resource  utlization  is  a  sub-objective 
of  the  primary  objective).  The  weight  of  the  maximum  alerts 


attribute  is  found  to  be  0.2.  This  value  indicates  that  20 
percent  of  the  overall  performance  measure  for  a  schedule  is 
determined  by  the  maximum  alerts  attribute.  All  of  the  oth¬ 
er  attribute  weights  can  be  determined  in  the  same  manner. 

The  weighting  scheme  is  shown  to  the  decision  maker,  and 
can  be  adjusted  if  the  decision  maker  feels  that  the  weights 
do  not  accurately  reflect  his  attitudes. 

With  the  weighted  hierarchy  completed,  alternative 
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schedules  can  be  scored  using  the  performance  measure.  The 
highest  score  is  the  best  alternative  schedule.  As  an  exam¬ 
ple,  assume  a  missile  wing  has  75  line  crews,  13  DOT/DOV 
crews,  and  15  flight  commander  crews.  Additionally,  assume 
that  the  scheduling  program  generated  a  schedule  that  con¬ 
tained  the  following  data: 

1.  Average  number  of  MPT  sessions  =  2.0. 

2.  Average  variance  in  class  size  -  4.5. 

3.  Average  number  of  alerts  =  6.5. 

4.  Variance  in  alert  rate  —  1.5. 

5.  Average  number  of  free  days  =  12.8. 

6.  Percentage  of  integral  alerts  =  75*. 

First,  the  worth  of  each  MOE  value  must  be  calculated. 
The  relationship  between  the  maximum  and  minimum  values  of 
the  MOE  and  the  worth  of  the  attribute  is  assumed  to  be 
1  inear . 

The  worth  of  the  measure  for  MPT  time  as  listed  in  Table 
IV- 1  is  1.0  for  an  average  of  two  MPT  sessions  per  crew. 

The  minimum  value  of  for  the  variance  in  class  sizes  is 
zero  while  the  maximum  value  must  be  calculated  analytical¬ 
ly.  If  it  is  assumed  that  the  class  sizes  range  between  18 
and  15  crews  and  that  a  maximum  of  10  days  of  classes  can  be 
offered,  then  the  maximum  variance  is  10.5.  Given  an  actual 
value  for  the  variance  of  4.5,  the  worth  of  this  attribute 
is  .57. 

The  upper  bound  for  the  alert  rate  was  assumed  to  be  8 
alerts  per  crew  for  this  example,  but  the  lower  bound  must 
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be  calculated  anal ytical 1 y .  Assuming  a  30  day  month  and 
that  DOT/DOV  crews  perform  2  alerts  per  month  and  -flight 
commander  crews  per-form  4  alerts  per  month,  the  75  line 
crews  must  per-form  364  alerts  to  insure  that  all  launch 
control  centers  are  manned  every  day.  This  is  equivalent  to 
an  alert  rate  o-f  4.85  alerts  per  month,  the  lower  bound. 
Again,  using  linear  interpolation,  the  worth  o-f  this  measure 
is  .48. 

The  lower  bound  -for  the  variance  in  alert  rates  is  zero, 
by  definition,  and  the  upper  bound  must  be  calculated.  The 
maximum  variance  can  be  found  if  the  minimum  number  of  crews 
perform  all  the  alerts,  and  the  rest  of  the  crew  force  per¬ 
form  zero  alerts.  This  variance  assumes  that  the  DOT/DOV 
and  flight  commander  crews  perform  their  usual  number  of 
alerts  per  month.  If  the  75  line  crews  must  perform  364 
alerts,  then  these  alerts  can  be  handled  by  45  line  crews 
performing  8  alerts,  and  one  additional  crew  performing  4 
alerts.  The  maximum  variance  based  on  this  information  is 
14.49.  With  an  actual  variance  of  1.5,  the  worth  of  this 
attribute  is  0.9. 

Free  days  are  defined  as  days  where  the  crew  has  no 
scheduled  duty  or  is  on  leave.  The  minimum  number  of  free 
days  is  0,  and  the  maximum  number  must  be  calculated  ana¬ 
lytically.  Given  that  the  minimum  alert  rate  is  4.85  alerts 
per  month,  the  number  of  free  days  will  be  30  minus  twice 
the  alert  rate  (count  each  alert  as  two  days,  one  day  for 
the  alert  and  one  day  for  return)  plus  four  training  days 
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< two  MPT  days  and  two  classroom  training  days).  The  maxi¬ 
mum  number  of  -free  days  is  16.3  days.  With  an  actual  value 
of  12.0  days,  the  interpolated  worth  value  is  .74. 

The  upper  and  lower  bounds  -for  integral  alerts  are  the 
same  as  the  worth  value  upper  and  lower  bounds,  that  is, 
zero  and  one  respective!  y .  The  worth  o-f  the  measure,  for 
this  example,  is  .75. 

Once  the  worth  values  for  the  six  lower  level  attributes 
have  been  determined,  the  performance  measure  for  the  sched¬ 
ule  can  be  found.  This  value  is  found  by  multiplying  the 
weight  of  the  attributes  by  the  calculated  worth  values  and 
summing  these  values. 

As  an  example,  if  the  weight  of  the  attribute  MPT  time 
<0.24)  is  multiplied  by  its  worth  value  (1.0)  to  determine 
the  performance  measure  value  for  this  one  attribute, 
this  case,  the  value  is  0.24.  The  same  calculation  can  be 
done  for  the  other  attributes  to  determine  their  performance 
measure  values.  These  values  for  the  other  attributes  in- 
cl ude: 

a.  Classroom  effectiveness — 0.0912. 

b.  Maximum  alerts — 0.096. 

c.  Difference  in  alert  rates — 0.18. 

d.  Free  days — 0.0888. 

e.  Integral  alerts — 0.06. 

The  performance  measure  values  for  each  of  the  attri¬ 
butes  is  summed  to  determine  the  performance  measure  for  the 
schedule.  For  the  example,  this  value  is  0.756. 
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The  use  of  the  worth  assessment  technique  provides  a 
method  of  comparing  different  scheduling  alternatives.  The 
problem  with  using  the  method  is  that  worth  independence  of 
the  attributes  must  be  assumed  or  proven.  Proving  worth  in¬ 
dependence  can  be  a  time  consuming  and  difficult  procedure. 
For  this  reason,  more  research  must  be  done  in  the  area  of 
performance  measures  for  evaluating  scheduling  alternatives. 
This  example  shows  one  possible  procedure  for  deriving  a 
performance  measure,  there  are  many  others.  Sensitivity 
analysis  will  be  done  in. the  experiment  to  find  how  the  per¬ 
formance  measure  varies  with  changes  in  the  values  used  in 
the  worth  assessment  procedure.  These  values  include:  the 
weights  of  the  attributes,  the  crew  force  structure,  the 
upper  and  1 ower  bounds  of  the  MOEs,  and  the  additional  user 
inputs  to  the  scheduling  program. 

A  HEURISTIC  APPROACH 

Response  surface  methodology  (RSM)  will  be  used  to  ana¬ 
lyze  the  set  of  alternative  schedules  in  this  experiment. 

RSM  is  an  analysis  tool  that  finds  the  best  levels  of  a 
given  set  of  variables,  called  factors,  that  create  the  best 
yield.  In  this  case  the  yield  is  the  performance  measure. 
The  approach  outlined  in  the  following  paragraphs  was 
adopted  from  Myers  <Ref  24) . 

This  experiment  lends  itself  to  RSM  techniques  because 
it  contains  a  number  of  factors  <the  variables  in  the 
scheduling  program)  that  affect  a  yield  (the  performance 


measure).  Additionally,  the  relationship  between  the  fac¬ 
tors  and  the  yield  is  unknown  and,  possibly,  complex.  This 
relationship  will  have  to  be  estimated,  which  makes  the  use 


of  techniques  such  as  mathematical  programming  difficult. 
RSM  graphically  depicts  the  relationship  of  the  factors  to 
the  yield.  Mathematical  programming  is  a  more  difficult 
technique  to  describe  to  a  layman  (such  as  a  decision 
maker),  and  the  relationship  of  the  variables  to  the 
performance  measure  is  not  as  easy  to  see.  Finally,  RSM 
should  give  the  researchers  a  better  understanding  of  the 
process  that  builds  the  schedule. 

The  output  from  the  scheduling  program  is  a  missile 
operations  schedule  plus  statistics  about  that  schedule. 
This  output  is  used  as  the  input  to  the  performance  measure 
equation.  The  independent  variables  in  the  scheduling  pro¬ 
gram  that  influence  the  schedule  must  be  determined.  These 
variables  are  the  factors,  and  the  yield  is  the  performance 
measure.  For  the  scheduling  program  the  independent  varia¬ 
bles  include: 

a.  Factors  internal  to  the  program: 

1.  The  percentage  of  time  that  a  DOT/DOV  crew  is 
selected  for  the  next  non-SCP  alert. 

2.  The  percentage  of  time  that  a  flight  commander 
crew  is  selected  for  the  next  non-scp  alert. 

3.  The  percentage  of  time  that  a  crew  is  selected 
for  the  next  alert  to  their  home  LCC. 

4.  The  percentage  of  time  that  a  DOT/DOV  crew  is 
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selected  for  an  SCP  alert 


5.  The  percentage  of  time  an  SCP  crew  is  selected 
for  the  next  SCP  alert  at  their  home  LCC. 

b.  Factors  external  to  the  program: 

1.  The  number  of  ACP/SCP  qualified  crews. 

2.  The  total  number  of  crews  in  the  crew  force. 

3.  The  number  of  days  that  a  crew  cannot  be  sched¬ 
uled  for  the  month. 

c.  Optional  factors  that  affect  the  schedule: 

1.  The  priority  rule  for  selecting  crews  from  the 
eligible  for  alert  queue. 

2.  The  maximum  number  of  alerts  that  each  crew 
type  can  perform. 

3.  The  maximum  and  minimum  class  size  for  class¬ 
room  training. 

The  factors  are  divided  into  three  groups  because  the 
number  of  factors  is  too  great  to  depict  graphically  if 
handled  as  one  group.  The  second  and  third  group  of  factors 
will  be  held  fixed  during  the  RSM  experiment  and  are  dis¬ 
cussed  in  the  sensitivity  analysis  portion  of  this  chapter. 
The  first  group  will  be  tested  in  the  experiment  to  deter¬ 
mine  the  best  internal  factors  for  the  performance  measure. 
The  factors  internal  to  the  model  represent  ways  in  which 
the  model  itself  can  be  changed  to  improve  the  quality  of 
the  schedule.  Factors  external  to  the  model  represent  a 
means  of  determining  the  best  crew  force  structure  for  a 
given  performance  measure.  The  optional  factors  represent 
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ways  that  the  decision  maker  can  improve  the  quality  o-f  the 
schedule  through  imp] ementabl e  policies. 

The  experimental  design  -for  this  research  effort  was 
originally  based  on  the  use  o-f  multivariate  regression 
techniques.  It  was  discovered  that  the  internal  -factors  o-f 
the  model  were  not  useable  with  regression  analysis,  how¬ 
ever.  The  interna]  factors  can  be  broken  into  two  groups: 
■factors  one,  two,  and  three  deal  with  selecting  the  next 
crew  -for  non-SCP  alerts,  and  factors  four  and  five  are  used 
in  selecting  crews  for  SCP  alerts.  The  factor  values  in 
each  of  these  groups  cannot  add  to  any  value  greater  than 
one.  There  are  many  values  within  the  factor  space  that 
each  factor  is  not  allowed  to  take  for  this  reason,  making 
the  variables  discontinuous.  Continuity  is  a  vital  assump¬ 
tion  in  regression  analysis  and  designing  regression  exper¬ 
iments  would  be  difficult  with  the  limitations  on  values 
that  the  variables  can  take.  An  alternate  experimental 
design  had  to  be  developed. 

The  revised  approach  is  a  heuristic  based  on  graphing 
the  response  surface  with  a  series  of  data  points  gathered 
throughout  the  factor  space.  Linear  interpolation  is  used 
to  fill  in  the  details  of  the  response  surface  that  have  not 
been  specifically  determined. 

The  three  major  factors  will  be  graphed  to  provide  an 
idea  of  the  best  area  on  the  response  surface  for  opera¬ 
tions.  The  major  factors  are  factors  one,  two,  and  three 
<the  percentage  of  time  that  a  DOT/DOV  crew,  integral  flight 
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coman der  crew,  and  integral  crew  are  selected  -for  the  next 
non-SCP  alert).  These  -factors  contribute  more  to  the  per¬ 
formance  measure  value  than  factors  four  and  five  <the  per¬ 
centage  of  time  a  DOT/DOV  crew  and  integral  crew  are  se¬ 
lected  for  the  next  SCP  alert)  because  they  contribute  to 
selecting  80  percent  of  the  alerts.  These  factors  are 
plotted  on  two  separate  graphs,  two  factors  versus  the 
performance  measure  value  on  each  graph.  The  areas  on  the 
graphs  where  the  performance  measure  values  are  the  highest 
are  looked  at  to  determine  a  best  factor  combination  of  the 
three  major  factors. 

Factor  combinations  in  these  smaller  areas  are  then 
closely  investigated  to  determine  the  best  factor  combina¬ 
tions.  Several  trials  are  used  to  determine  the  value  of 
each  data  point.  The  means  and  variances  of  the  data  points 
are  computed  and  compared  to  determine  the  best  factor  set¬ 
tings. 

The  best  settings  of  factors  four  and  five  are  found  by 
varying  the  levels  of  these  factors  using  ten  data  points 
from  the  first  experiment.  The  means  and  variances  of  these 
data  points  will  be  calculated  to  determine  the  best  factor 
settings  for  factors  four  and  five.  The  best  factor  setting 
based  on  the  alternative  schedules  examined  can  be  found  in 
this  manner. 

THE  EXPERIMENT 

The  performance  measure  used  in  the  experiment  is  the 
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same  performance  measure  outlined  earlier  in  this  chapter. 
The  objectives  hierarchy  and  attribute  weights  are  shown  in 
Figure  IO-3. 

This  performance  measure  was  developed  as  one  represent¬ 
ative  performance  measure.  Two  other  possible  measures  are 
checked  in  the  sensitivity  analysis  portion  of  this  chapter. 
Several  inputs  normal  1 y  supplied  to  the  program  by  the 
scheduler  were  fixed  for  the  purposes  of  the  experiment. 

The  crew  force  size  was  fixed  at  90  crews  consisting  of  15 
flight  commander  crews,  21  DOT/DOO  crews,  and  54  line  crews. 
These  crews  can  perform  a  maximum  of  four,  two,  and  eight 
alerts,  respectivel y .  This  crew  force  structure  was  se¬ 
lected  because  it  is  typical  of  all  three-squadron  SM*Js. 

The  class  size  range  for  classroom  training  was  set 
between  six  and  fifteen  crews  per  class  with  a  maximum  of 
twelve  training  days  available  for  each  training  type.  Two 
types  of  classroom  training  and  one  MPT  session  were  given 
to  each  crew  every  month.  These  values  are  all  represent¬ 
ative  of  normal  values  for  these  inputs. 

Additionally,  the  EA  queue  used  the  fewest  number  of 
alerts  performed  to  date  as  a  priority  rule  for  searching 
the  file  for  the  next  crew  to  perform  alert.  The  external 
factors  for  this  experiment  were  set  to  a  maximum  crew  force 
<90  crews)  and  a  minimum  number  of  SCP  crews  <39> .  This 
crew  force  structure  is  also  typical  for  three-squadron 
SMWs. 

A  total  of  51  data  points  was  gathered  throughout  the 


10-20 


MAINTAIN  CREDIBLE 
DETERRENT  CAPABILITY  (1.8) 


TRAINING  < .48) 
EFFECTIVENESS 


RESOURCE  (.48) 
UTILIZATION 


MORALE 
<  .28) 


MPT  TIME  CLASSROOM  ALERT  ALERT 

< . 68)  EFFECTIVENESS  RATE  VARIANCE 

<  .48)  < . 58)  < .58) 


INTEGRAL  FREE 
ALERTS  DAYS 
(.48)  ( .68) 


Figure  IV-3.  Objectives  Hierarchy  -for  The  Experiment 

factor  space  for  graphing  the  response  surface.  At  least 
four  trials  of  each  data  point  were  made.  The  average 
performance  measure  value  for  each  data  point  was  computed 
from  the  trials  and  used  in  the  plotting  of  the  repsonse 
surface. 

Factors  one,  two,  and  three  were  graphed  separately 
against  the  performance  measure  first  to  see  if  any  one 
factor  appeared  to  be  linearly  related  to  the  performance 
measure.  These  graphs  are  in  the  back  of  this  chapter  in 
Figures  IV-5  through  IV-7. 

The  graphs  show  the  performance  measure  is  directly 
proportional  to  factor  three  and  inversely  proportional  to 
factors  one  and  two.  The  graphs  also  indicate  that  the  best 
area  for  the  performance  measure  appears  to  be  between  8.8 
and  8.3  for  factor  one;  8.8  and  8.2  for  factor  two;  and  8.6 
and  i.8  for  factor  three. 

From  this  information,  it  was  decided  that  factors  one 
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and  two  would  be  graphed  against  factor  three  and  the  per¬ 
formance  measure  to  determine  the  shape  of  the  response 
surface  and  the  location  of  the  best  factor  area. 

The  graphs  for  the  response  surface  were  plotted  on  a 
Hewlitt  Packard  HP7228A  plotter  using  the  S  statistical 
language  and  a  MAX  11-780  computer.  The  graphs  are  plotted 
in  a  three-dimensional  perspective  format.  The  graphs  for 
the  repsonse  surface  are  included  at  the  end  of  this  chap¬ 
ter  . 

Factors  four  and  five  were  checked  against  ten  different 
data  points  from  the  experiment.  Five  levels  of  these  two 
factors  were  originally  run  for  each  data  point.  The  re¬ 
sults  showed  that  the  best  factor  levels  for  factors  four 
and  five  were  between  0.1  to  0.3  and  0.7  to  0.9  respective¬ 
ly.  Two  additional  data  runs  were  made  for  each  of  the  ten 
data  points  to  see  if  there  was  a  single  best  factor  level 
for  each  of  these  two  factors  in  this  area. 


EXPERIMENTAL  RESULTS 

Ten  data  points  were  checked  in  the  area  of  highest  per¬ 
formance  measure  values  to  determine  what  the  best  factor 
combinations  for  factors  one,  two,  and  three  were.  The  data 
points  were  picked  as  a  representative  cross  section  of  the 
nineteen  data  points  in  the  area  of  interest.  These  data 
points  are  listed  in  Appendix  B.  Two  data  points  were  found 
to  be  better  than  all  of  the  others  in  the  area.  The  sta¬ 
tistical  tests  used  to  compare  the  data  points  are  also  con- 
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tained  in  Appendix  B.  The  variances  of  the  data  points  were 


■first  tested  -for  equality  with  an  F-test.  I-f  the  variances 
were  equal  ,  a  T-test  was  used  to  test  the  means  o-f  the  per¬ 
formance  measure  values.  A  Wi 1 coxon-Mann-Whi tney  rank  sum 
test  was  used  to  test  the  means  o-f  the  values  if  the  vari¬ 
ances  were  found  to  be  different.  The  factor  combinations 
of  0.1,  0.1,  0.8  and  0.2,  0,  0.8  for  interna)  factors  one, 
two,  and  three,  respec t ivel y ,  were  found  to  produce  the  best 
schedules  in  terms  of  performance  measure  values.  The  data 
points,  means,  and  variances  are  summarized  in  Table  IU-2. 

Factors  four  and  five  were  compared  in  a  similar  manner 
and  two  factor  settings  were  found  to  be  better  than  all 
others  for  these  factors.  Factor  values  of  .1  and  .2  for 
factor  four  and  .9  and  .8  for  factor  five  were  determined  to 
produce  the  best  schedules.  These  data  points  and  their 
means  and  variances  are  summarized  in  Table  IV-3. 

What  these  factor  settings  mean  are  that  setting  the 
program  to  select  a  DOT/DOV  crew  for  the  next  non-SCP  alert 
ten  percent  of  the  time,  selecting  a  flight  commander  for 
alert  at  his  home  LCC  ten  percent  of  the  time,  selecting  an 
integral  crew  for  the  next  alert  eighty  percent  of  the  time; 
selecting  a  DOT/DOV  crew  for  the  next  SCP  alert  ten  percent 
of  the  time,  and  selecting  an  integral  crew  for  the  next  SCP 
alert  ninety  percent  of  the  time  produces  the  best  schedule 
for  this  performance  measure.  Setting  these  factors  to 
levels  of  twenty,  zero,  eighty;  twenty  and  eighty  percent, 
respec t ivel y ,  produces  an  equally  good  schedule. 


Table  IV-2.  Best  Data  Points  ■for  Factors 

One,  Two,  and  Three  for  Performance 
Measure  One 


Number  of 
Observations 

Data 

FI 

Points 

F2  F3 

Measure 

Mean  Variance 

16 

0.1 

0.1 

CD 

a 

ck 

0.954 

4.87E-5 

10 

0.1 

0.3 

0.6 

0.955 

2.82E-5 

10 

0.1 

0.2 

0.7 

0.958 

4.09E-5 

14 

0.1 

0.1 

<s 

a 

CD 

0.964 

2.42E-5 

10 

0.1 

CD 

a 

CD 

0.9 

0.933 

4.75E-5 

18 

0.2 

0.2 

0.6 

0.958 

6. 19E-5 

12 

0.2 

0.1 

CD 

a 

N» 

0.960 

7.30E-5 

10 

0.2 

0.0 

0.8 

0.961 

9.85E-5 

10 

0.3 

0.1 

0.6 

0.95? 

9.54E-6 

12 

0.3 

0.0 

0.7 

0.958 

3.35E-5 

The  other  factor  combi nat i ons  in  this  area  also  produce 
reasonable  schedules.  That  is,  the  performance  measure 
values  for  these  factor  combinations  are  almost  as  good  as 
the  two  best  factor  combinations.  This  means  that  the  op¬ 
timal  area  for  this  performance  measure  is  relatively  flat 
as  can  be  seen  from  the  response  surfaces  depicted  in 
Figures  IV-8  and  IV-?. 

The  internal  factors  only  affect  the  integral  alert  rate 
of  the  schedule.  This  is  true  until  the  DOT/DOV  crews  stop 
performing  their  maximum  number  of  alerts.  This  event  oc¬ 
curs  when  internal  factor  one  is  set  too  low.  Factor  one 
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Table  IV-3.  Factors  Four  and  Five  Values  Used 

in  Determining  the  Best  Levels  of  These 
Factors  -for  Performance  Measure  One 


Number  of 

Factor 

Level s 

Performance  Values 

Observat i ons 

4 

5 

Mean 

Variance 

10 

0.1 

0.9 

0.953 

2.30E-5 

10 

0.2 

0.8 

0.956 

7. 16E-5 

10 

0.3 

0.7 

0.951 

7.70E-5 

10 

0.4 

0.6 

0.943 

4.50E-5 

10 

0.6 

0.4 

0.944 

7. 18E-5 

10 

0.8 

0.2 

0.942 

6.30E-5 

10 

1.0 

0.0 

0.943 

9.00E-5 

must  be  set  high  enough  to  insure  that  the  DOT/DOV  crews 
perform  at  least  42  alerts  per  month.  This  number  of  alerts 
is  roughly  equal  to  nine  percent  of  the  total  alert  load 
that  must  be  performed.  If  the  DOT/DOV  crews  do  not  perform 
their  42  alerts,  the  alert  rate  and  the  variance  in  alert 
rate  for  the  line  crews  increase;  the  number  of  free  days 
also  decreases.  This  causes  the  performance  measure  value 
for  the  schedule  to  decrease.  The  results  of  the  analysis 
also  indicate  that  the  variance  in  the  model  is  small  with 
little  change  occuring  over  a  broad  area  of  the  response 
surface.  This  result  can  be  seen  by  examining  the  variances 
listed  in  Tables  IV-2  and  IV-3. 

Finally,  the  results  of  the  experiments  show  that  sched¬ 
uling  alternatives  can  be  compared  by  the  method  outlined  in 
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this  chapter.  The  best  internal  factor  setting  for  the 
alternative  schedules  examined  can  be  found  using  this 
method  for  a  given  performance  measure. 


SENSITIVITY  ANALYSI S 

Sensitivity  analysis  of  the  results  obtained  in  this 
experiment  are  considered  next.  This  analysis  will  look  at 
several  program  variables.  The  effect  on  internal  factor 
settings  using  different  performance  measures  will  be  dis¬ 
cussed  first.  The  effect  of  having  the  entire  crew  force 
ACP/SCP  qualified  will  be  presented  next.  The  effect  on  the 
performance  measure  of  adding  an  assumed  leave  distribution 
to  the  schedule  inputs  will  be  looked  at  third.  The  effect 
of  changing  the  priority  rule  for  searching  the  eligible  for 
alert  queue  will  be  investigated  fourth.  Finally,  the  ef¬ 
fect  of  scheduling  a  31  day  month  will  be  examined. 


ADDITIONAL  PERFORMANCE  MEASURES 

Two  additional  performance  measures  were  built  to  see 
how  they  affected  the  selection  of  the  internal  factor  set¬ 
tings.  The  second  performance  measure  equally  weights  all 
attributes.  This  performance  measure  is  designed  to  be  a 
baseline  or  "middle  of  the  road"  performance  measure.  The 
third  performance  measure  is  designed  to  be  the  opposite  of 
the  original  performance  measure  used  in  the  experiment. 
This  performance  measure  heavily  weights  morale  and  lightly 
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weights  training.  Both  of  these  performance  measures  are 
outlined  in  Figure  IY-4  a  and  b. 

The  data  points  -from  the  experiment  were  used  in  this 
analysis  and  the  performance  measure  values  were  recomputed 
using  the  two  new  performance  measures.  The  same  graphical 
and  statistical  analysis  were  applied  to  the  two  new  per¬ 
formance  measures  used  in  the  experiment.  The  results  in¬ 
dicate  that  the  same  internal  factor  settings  are  best  for 
al 1  three  performance  measures.  Graphs  of  the  response 
surfaces  for  these  analyses  are  included  in  the  back  of  this 
chapter  as  Figures  IY-18  through  IV-13. 

The  results  of  these  analyses  show  that  changing  per¬ 
formance  measures  does  not  change  the  internal  factor  set¬ 
tings.  These  results  indicate  that  the  scheduling  model 
internal  factors  maybe  insensitive  to  changes  in  the  per¬ 
formance  measure.  If  this  is  true,  the  internal  factor 
settings  are  independent  of  the  performance  measure  and 
could  be  put  into  the  model  as  constants. 


INCREASING  THE  NUMBER  OF  ACP/SCP  CREWS 

The  original  hypothesis  was  that  an  increase  in  the  num¬ 
ber  of  SCP  qualified  crews  would  increase  the  performance 
measure  value  of  the  schedule  by  decreasing  the  variance  in 
the  alert  rate  of  the  crew  force.  Twenty  one  data  points 
from  the  original  experiment  were  repeated  with  the  entire 
crew  force  ACP/SCP  qualified.  These  data  points,  their 
means,  and  variances  are  summarized  in  Table  IV-4. 
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a .  Performance  Measure  Two 
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b.  Performance  Measure  Three 
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Figure  IV-4  a  and  b.  Objectives  Hierarchy  for  Performance 

Measures  Two  and  Three 


The  analysis  of  the  data  points  is  included  in  Appendix  B. 
The  results  indicate  that  the  performance  measure  value 
actually  decrease  or  remains  the  same  for  an  all  ACP/SCP 


Performance  Mean  Variance  <xE-4> 


Measure 

Min 

Max 

Min 

Max 

1 

.921 

.918 

1 .  17 

.679 

2 

.855 

.843 

4.87 

3. 19 

3 

.828 

.800 

10.2 

10.4 

crew  force.  The  reason  for  this  is  a  decrease  in  the  inte¬ 
gral  alert  rate.  The  integral  alert  rate  decreases  because 
all  crews  now  perform  alerts  at  three  additional  launch 
control  centers.  The  alert  rate  and  the  variance  in  alert 
rate  are  not  changed  by  increasing  the  number  of  SCP  crews. 
This  also  indicates  that  increasing  the  number  of  SCP  qual¬ 
ified  crews  can  only  decrease  the  performance  measure  value 
of  the  schedule.  One  caveat,  however,  must  be  placed  on 
this  conclusion.  The  results  were  obtained  by  looking  at  a 
schedule  with  no  leave  distribution  assumed  for  the  crew 
force.  The  results  of  this  analysis  may  be  different  for  a 
schedule  where  some  leave  distribution  is  assumed.  SCP 
crews  on  leave  could  increase  the  alert  rate  of  the  remain¬ 
ing  SCP  crews  unless  there  were  extra  crews  to  help  perform 
SCP  alerts. 

ADDING  LEAVE  TO  SCHEDULE  INPUTS 


The  effect  of  adding  an  assumed  leave  distribution  to 


the  scheduling  inputs  is  discussed  in  this  section.  Eleven 
data  points  -from  the  original  analysis  were  re-run  with  an 
assumed  leave  distribution  -for  the  crew  force  inserted  into 
the  scheduling  program.  These  data  points,  means,  and  vari¬ 
ances  are  presented  in  Table  IV-5.  The  schedule  from  the 
44th  Strategic  Missile  Wing  that  was  used  for  verification 
and  validation  was  examined  and  a  leave  distribution  for  the 
crew  force  was  postulated.  The  data  points  used  and  the 
statistical  calculations  performed  are  also  contained  in 
Appendix  B. 

The  results  of  this  analysis  show  a  decrease  in  the  per¬ 
formance  measure  value,  but  no  change  in  the  shape  of  the 
response  surface.  The  decrease  in  performance  measure  value 
is  due  to  an  increase  in  the  variance  in  alert  rates  and  a 
decrease  in  the  MPT  rate.  Also  several  crews  must  be  sched¬ 
uled  for  individual  classroom  training  because  of  the  large 
amount  of  leave  taken.  The  analysis  also  shows  that  the 
program  is  capable  of  functioning  with  an  assumed  leave 
distribution.  The  ability  of  the  program  to  function  with  a 
leave  distribution  was  also  demonstrated  in  the  validation 
section  of  this  report.  This,  once  again,  shows  that  the 
program  is  capable  of  building  a  feasible  schedule. 


CHANGING  THE  EA  QUEUE  PRIORITY  RULES 

Two  different  priority  rules  were  tested  for  the  elig¬ 
ible  for  alert  < EA)  queue.  The  first  rule  was  Last  In  First 
Out  <LIFO>  and  the  second  was  First  In  First  Out  (FIFO). 
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Table  IV-5.  Results  of  Analysis  of  Leave  vs.  Non-Leave 
Schedul es 


Perf ormance 

Mean 

Variance 

(  xE-4) 

Measure 

Leave 

No  Leave 

Leave 

No  Leave 

1 

.892 

.924 

1 .62 

.734 

2 

.829 

.859 

3.45 

2.83 

3 

.785 

.827 

5.99 

7.53 

LIFO 

priority  rule 

increases 

the  alert 

var i ance 

for 

rews 

to  over  4.0. 

The  reason 

for  this 

i  ncrease 

i  s 

that  crews  returning  to  the  EA  queue  from  alert  have  the 
highest  priority  for  selection  to  go  back  on  alert.  The 
same  crews  ar  performing  a  number  of  back-to-back  alerts 
before  any  other  crews  are  considered  for  alert  duty.  New 
crews  are  selected  for  alert  only  as  crews  performing  back- 
to-back  alerts  complete  their  maximum  number  of  alerts. 

This  causes  a  large  imbalance  in  the  number  of  alerts  a 
given  crew  might  perform,  driving  the  variance  in  alert  rate 
up.  This  is  not  a  useful  strategy,  based  on  the  performance 
measures  used  in  this  report  because  it  always  reduces  the 
performance  measure  value  of  the  schedule. 

The  FIFO  priority  rule  is  very  similar  to  the  fewest 
alerts  priority  rule  that  was  used  in  the  experiment.  Wi th 
the  FIFO  rule,  crews  are  all  cycled  through  the  EA  queue 
before  a  crew  that  has  previously  performed  alert  is  se¬ 
lected.  The  attribute  values  recorded  for  this  priority 
rule  are  identical  to  the  attribute  values  seen  in  the 
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experiment  for  the  same  internal  factor  settings.  This 
indicates  that  using  the  FIFO  rule  produces  the  same  re¬ 
sults,  in  the  scheduling  policies  examinee  as  the  fewest 
alerts  rule. 


THE  31  DAY  MONTH 


Several  program  runs  were  made  using  a  31  day  month.  An 


increase  in  the  alert  rate  and  free  days  was  noted  because 


of  the  extra  day.  Adding  an  extra  day  to  the  month  con¬ 


strains  the  programs  ability  to  find  crews  for  alert,  be¬ 


cause  many  crews  have  already  performed  their  maximum  number 


of  alerts  by  the  31st  day.  The  number  of  ACP/SCP  qualified 


crews  is  a  particular  problem.  If  there  is  an  inadequate 


number  of  ACP/SCP  crews  the  SCPs  may  not  be  manned  on  the 


31st  day.  For  a  crew  force  of  39  ACP/SCP  qualified  crews, 


however,  the  program  did  not  have  a  problem.  Once  again, 


this  analysis  was  performed  with  no  leave  assumed.  The 


results  may  be  different  with  a  leave  distribution. 


RESULTS 


The  internal  factors  of  the  scheduling  program  are  ro¬ 


bust  to  changes  in  the  performance  measure  used  to  Judge  the 


schedule.  This  means  that  these  factors  may  not  have  to  be 


changed  for  each  new  performance  measure.  Adding  an  assumed 


leave  distribution  to  the  schedule  inputs  does  decrease  the 


performance  measure  value  of  the  schedule,  but  the  response 
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surface  generated  is  the  same  shape. 

Increasing  the  number  of  ACP/SCP  personnel  decreases  the 
performance  measure  value  of  the  schedule  because  the  inte¬ 
gral  alert  rate  is  decreased.  This  result  may  be  different 
if  a  leave  distribution  is  assumed.  If  a  number  of  ACP/SCP 
crews  are  on  leave  at  the  same  time  there  could  be  a  problem 
manning  all  SCP  launch  control  centers,  forcing  the  alert 
rate  up  for  SCP  qualified  crew  members. 

One  external  factor  and  two  optional  factors  were  not 
addressed  in  the  sensitivity  analysis  section.  It  was  be¬ 
lieved  that  changing  the  total  number  of  crews  in  the  crew 
force  would  be  of  little  benefit  in  this  analysis.  Any  de¬ 
crease  in  the  size  of  the  crew  force  will  increase  the  alert 
rate  and  decrease  the  performance  measure  value.  Therefore, 
the  best  crew  force  size  is  the  biggest  crew  force  possible. 
Changing  the  maximum  number  of  alerts  for  a  crew  type  would 
improve  the  performance  measure  value  of  the  schedule,  but 
the  suggestion  is  not  practical.  Flight  commander  crews  and 
DQT/DOV  personnel  are  responsible  for  many  other  duties  that 
preclude  an  increase  in  their  alert  rate.  Increasing  the 
maximum  number  of  alerts  for  line  crews  should  have  no  ef¬ 
fect  as  they  already  perform  whatever  alerts  are  necessary. 
Finally,  changing  the  maximum  and  minimum  values  of  class 
sizes  is  not  an  important  consideration.  A  class  size  range 
of  between  6  and  15  crews  is  very  large  and  is  typical  of 
class  sizes  seen  at  ShWs  now. 


IV-33 


•unaDs^j  •ouDuiJO 


,V~J 

r\J- 


IV-38 


CHAPTER  U 


SUMMARY  AND  CONCLUSIONS 


SUMMARY  OF  RESEARCH 

This  research  effort  was  directed  toward  the  development 
of  a  computerized  scheduling  system  for  missile  combat  crews 
at  a  strategic  missile  wing.  The  scheduling  program  takes  a 
number  of  inputs  from  the  user  and  returns  a  monthly  sched¬ 
ule.  The  user  must  input  several  pieces  of  information 
about  the  crew  force  including  the  number  of  crews,  the  num¬ 
ber  of  each  type  of  crew,  the  home  launch  control  center  of 
each  crew,  the  number  of  leave  periods  the  crew  has,  and  the 
duration  of  each  leave  period.  The  number  of  days  available 
for  classroom  training  to  be  given  must  also  be  input  along 
with  the  different  type  of  classroom  training.  The  class 
size  range  for  each  type  of  classroom  training  must  be  input 
also.  The  number  of  MPT  periods  available  each  day,  and  the 
number  of  MPT  sessions  that  each  crew  should  receive  are 
other  inputs.  The  user  must  also  provide  a  maximum  number 
of  alerts  for  each  crew  type.  In  addition  to  these  inputs, 
the  user  must  also  set  five  internal  factors.  These  factors 
control  the  program's  method  of  searching  for  the  next  crew 
to  go  on  alert.  These  factors  include: 

Factor  1:  The  percentage  of  time  a  DOT/DOV  crew  is 

chosen  to  perform  the  next  alert  at  a  non- 


SCP  launch  control  center  <LCC>  . 

Factor  2:  The  percentage  of  time  a  -flight  commander 

crew  is  chosen  to  perform  the  next  alert  at 
the  crew's  home  LCC. 

Factor  3:  The  percentage  of  time  a  crew  is  chosen  to 
perform  alert  at  their  home  LCC. 

Factor  4:  The  percentage  of  time  a  DOT/DOV  crew  is  se¬ 
lected  to  perform  the  next  alert  at  an  SCP. 

Factor  5:  The  percentage  of  time  a  crew  is  selected  to 
perform  alert  at  their  home  LCC  that  is  an 
SCP. 

The  output  from  the  scheduling  program  is  an  initial 
monthly  operations  schedule.  The  program  has  scheduled 
alerts,  training,  and  leave  for  all  crews.  The  program 
prints  out  a  series  of  statistics  in  addition  to  the  monthly 
schedule.  These  statistics  include  the  alerts,  integral 
alerts,  leave  days,  and  free  days  for  every  crew.  Also  the 
mean  and  variance  of  alerts,  integral  alerts,  and  free  days 
are  printed  for  the  1 ine  crews. 

Some  manual  manipulation  of  the  schedule  is  usually  nec¬ 
essary,  depending  on  the  inputs  to  the  program.  This  manual 
reworking  of  the  schedule  does  not  take  a  significant  amount 
of  time. 

An  example  has  been  presented  of  how  to  compare  alterna¬ 
tive  schedules  through  the  use  of  a  performance  measure. 

The  method  was  developed  to  enable  schedulers  to  produce 
several  schedules,  to  compare  these  schedules,  and  to  select 


the  schedule  that  best  matches  the  user's  criteria  o-f  a  good 
schedul e. 

RESULTS 

An  experiment  was  conducted  that  compared  schedules,  and 
the  results  were  used  to  -find  the  best  set  o-f  internal  fac¬ 
tors  for  the  performance  measure  used.  Over  208  data  runs 
were  completed  in  the  experiment  and  over  50  data  points 
were  gathered.  Two  other  performance  measures  were  devel¬ 
oped,  and  the  data  was  used  to  find  the  best  factor  settings 
for  these  measures  also. 

Additionally,  11  data  points  were  gathered  with  a  leave 
distribution  for  the  crew  force.  The  results  of  these  runs 
were  compared  to  the  experimental  results.  An  additional  21 
data  points  were  checked  with  a  different  percentage  of  SCP 
qualified  crew  members.  These  runs  were  also  compared  to 
the  experimental  results. 

A  large  amount  of  data  was  gathered  concerning  the 
scheduling  program.  This  data  was  analyzed  to  better  under¬ 
stand  how  the  program  works  and  how  to  produce  the  best  pos¬ 
sible  schedules  with  the  program. 

RESEARCH  METHODS 

The  SLAM  simulation  language  was  used  to  build  the 
scheduling  program.  For  alerts,  missile  combat  crews  were 
modeled  as  entities  flowing  through  a  network.  Other  ac- 


tivities,  such  as  leave  and  selection  o-f  the  next  crew  -for 
alert  were  modeled  as  discrete  events.  Classroom  and  MPT 
training  were  scheduled  -following  the  simulation  o-f  the 
month's  alerts.  Finally,  crew  statistics  were  collected 
from  the  schedule. 

Crews  were  scheduled  for  leave  based  on  the  information 
given  to  the  program  by  the  user.  Crews  were  scheduled  for 
alerts  by  using  search  routines  that  selected  the  next  crew 
for  alert  based  upon  the  internal  factors,  and  a  priority 
rule.  The  priority  rule  defines  which  crew  should  be  se¬ 
lected  for  the  next  alert.  The  priority  rule  used  in  the 
experiment  was  that  the  crew  with  the  fewest  alerts  was  giv¬ 
en  highest  priority  to  be  selected  for  alert.  Crews  were 
scheduled  for  classroom  training  by  using  a  search  routine 
that  seeks  to  minimize  the  number  of  training  days  used 
within  the  constraint  of  a  given  class  size  range.  Crews 
were  scheduled  for  available  MPT  sessions  with  a  similar 
search  routine.  Statistics  were  calculated  after  the  sched¬ 
ule  had  been  completed. 

The  program  was  verified  by  checking  each  program  module 
output  against  what  was  expected.  The  program  was  built  in 
modules  to  facilitate  this  process.  The  program  modules  in¬ 
clude:  input,  initialization,  scheduling  leave  and  alerts, 

scheduling  classroom  training,  scheduling  MPT  sessions,  com¬ 
puting  statistics,  and  program  output. 

The  program  was  validated  by  comparing  its  output  to  an 
existing  missile  combat  crew  schedule  from  Ellsworth  AFB. 


The  scheduling  program  was  given  the  inputs  to  this  schedule 
and  the  output  closely  matched  (actually  performs  better 
than)  the  existing  schedule. 

Worth  assessment,  a  Mul ti-Cri teria  Decision  Theory  tech¬ 
nique  was  used  to  develop  a  performance  measure  for  the 
schedules.  This  technique  uses  a  six  step  process  for  de¬ 
veloping  a  performance  measure.  The  six  steps  include: 

1.  List  the  objectives  for  the  schedule. 

2.  Develop  physical  measures  for  these  lower  level 
attributes. 

3.  Determine  the  relationship  between  the  lower  level 
attributes  and  the  physical  measure. 

4.  Determine  the  relationship  between  the  physical 
measure  and  the  worth  of  that  attribute. 

a.  The  worth  of  the  attribute  is  described  by  a 
number  between  zero  and  one. 

b.  The  relationship  between  the  maximum  and  mini¬ 
mum  values  of  the  physical  measure  and  the 
worth  score  must  be  linear. 

5.  Determine  the  relative  weights  of  the  attributes. 

6.  Adjust  these  weights  as  necessary  to  insure  that  the 
decision  maker  has  confidence  in  the  performance 
measure. 

Response  surface  methodology  was  used  to  compare  the 
alternative  schedules,  and  to  find  the  best  internal  factor 
settings  for  the  performance  measure  developed.  Response 
surface  methodology  allows  several  factors  to  be  varied  to 


■find  the  best  yield  (in  this  case  a  performance  measure 
val  ue)  . 

Three  different  performance  measures  were  compared  by 
testing  the  means  and  variances  of  the  data  runs  to  see  if 
the  performance  measure  values  differed  significantly  from 
one  another.  The  results  from  changing  the  number  of  SCP 
qualified  crews  and  from  assuming  a  leave  distribution  were 
compared  in  the  same  manner.  Both  of  these  changes  were 
compared  to  the  experimental  performance  measure  values  de¬ 
veloped  first. 


CONCLUSIONS 

The  primary  result  of  this  research  was  the  determina¬ 
tion  that  SLAM  can  be  used  to  develop  a  feasible  missile 
combat  crew  scheduling  program.  This  schedule  can  be  pro¬ 
duced  much  faster  than  by  the  manual  method  now  used.  In 
addition,  the  results  indicate  that  the  schedule  may  be 
better  depending  on  the  performance  measure  used  to  judge 
the  schedules. 

A  method  was  also  developed  that  allows  quantitative 
comparison  of  scheduling  alternatives.  The  method  also  can 
be  used  to  determine  the  best  setting  for  the  internal  fac¬ 
tors  of  the  model  for  a  given  performance  measure.  The  in¬ 
ternal  factors  of  the  model  were  found  to  be  robust  across 
several  different  performance  measures.  This  tends  to  indi 
cate  that  the  internal  factor  setting  can  be  adjusted  for 


any  given  performance  measure.  The  experiment  conducted 


also  shows  that  the  response  surfaces  of  the  various 


performance  measures  have  the  same  shape. 

The  introduction  of  an  assumed  leave  distribution  de¬ 
creases  the  value  of  the  performance  measure  observed.  An 
increase  in  the  alert  variance  and  a  decrease  in  the  MPT 
session  percentage  is  the  cause  of  this.  A  smaller  crew 
force  would  always  have  a  lower  performance  measure  value 
because  the  program  produces  a  schedule  that  has  a  near 
minimum  alert  rate.  Any  decrease  in  the  crew  force  would 
cause  an  increase  in  the  alert  rate,  and  a  corresponding 
decrease  in  the  performance  measure  value. 

An  all  SCP  qualified  crew  force  also  is  not  desirable, 
although  the  reason  for  this  is  less  obvious.  An  all  SCP 
crew  force  causes  a  decrease  in  the  integral  alert  rate 
causing  a  lower  performance  measure  value.  When  all  crews 
are  SCP  qualified  this  increases  the  number  of  different 
LCCs  where  the  crew  must  perform  alerts,  thus  lowering  the 
integral  alert  rate.  Since  this  analysis  was  conducted 
without  an  assumed  leave  distribution  for  the  crew  force, 
some  additional  SCP  crews  would  improve  the  performance 
measure  value  of  a  schedule,  especially  if  a  large  number  of 
SCP  crews  were  on  leave  at  one  time.  In  this  case,  addi¬ 
tional  SCP  crews  would  lower  the  alert  rate  and  the  variance 
in  alert  rate  and  would  offset  the  decrease  in  the  integral 
alert  rate. 

One  final  lesson  learned  from  this  research  effort  is 
the  need  for  a  data  base  for  this  scheduling  model.  A  data 


base  could  hold  all  the  crew  information  that  must  currently 
be  input  into  the  scheduler  every  time  it  is  run.  The  data 
base  could  also  hold  additional  information  on  arrival  and 
departure  of  personnel ,  periodic  appointments,  and  other 
constraints  on  the  scheduling  program.  This  data  base  could 
allow  rapid  changes  to  the  schedule.  Without  a  data  base 
that  a  scheduler  can  use  to  call  up  information  and  make 
decisions,  the  program  is  of  limited  use  in  making  day-to- 
day  schedule  changes.  With  a  data  base,  a  scheduler  could 
call  up  the  needed  information,  decide  how  to  change  the 
schedule,  and  input  the  change  into  the  scheduling  program 
rapidly.  Such  a  system  is  a  Decision  Oriented  Scheduling 
System,  and  would  be  of  great  value  to  missile  operations 
and  missile  maintenance  schedulers. 

USES  FOR  THE  SCHEDULING  PROGRAM 

As  written,  the  scheduling  program  gives  wing  schedulers 
the  ability  to  quickly  produce  a  high  quality,  initial 
monthly  schedule.  The  program  also  can  produce  several  al¬ 
ternative  schedules  that  can  be  compared  in  the  manner  de¬ 
scribed  in  Chapter  IV  of  this  report.  The  program  cannot  be 
used  for  making  daily  schedule  changes,  however,  without  the 
addition  of  a  data  base. 

The  program  also  can  be  used  to  forecast  crew  require¬ 
ments.  The  future  requirements  can  be  input  into  the  pro¬ 
gram  and  various  force  structures  can  be  examined.  The  best 
force  structure  can  be  chosen  and  employed.  This  method 
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would  work  even  better  if  the  program  was  provided  with  the 
data  bases  previously  discussed. 


RECOMMENDATIONS  FOR  FURTHER  RESEARCH 

This  research  effort  can  be  thought  of  as  the  first  part 
of  a  Strategic  Missile  Ming  Decision  Oriented  Scheduling 
System  (DOSS).  The  complete  DOSS  would  include  a  missile 
operations  scheduler  and  data  base;  a  missile  maintenance 
scheduler  and  data  base;  a  missile  status  data  base;  an 
interface  between  the  data  bases  and  the  scheduler,  and  an 
interface  between  the  DOSS  and  the  users.  This  DOSS  would 
decrease  the  amount  of  time  currently  spent  scheduling  mis¬ 
sile  operations  and  maintenance  requirements.  Information 
about  the  various  components  of  the  missile  wing  would  be 
readily  available  allowing  decisions  to  be  made  with  the 
latest  and  most  complete  information. 

The  scheduling  program  also  may  require  a  different 
method  of  developing  a  performance  measure.  Other  MCDT 
techniques  are  available  that  would  provide  a  more  detailed 
performance  measure  for  the  decision  maker.  These  tech¬ 
niques,  however,  are  time  consuming  and  require  a  great  deal 
of  research.  Ualue  functions  would  have  to  be  elicited  from 
wing  decision  makers  as  a  starting  point  in  the  construction 
of  more  accurate  performance  measures. 

In  addition,  more  sensitivity  analysis  is  needed  for  the 
scheduling  program  itself.  The  effects  of  changing  leave 
distributions,  changing  the  MPT  requirements  for  each  crew, 


and  changing  to  different  performance  measures  should  be 
addressed.  A  method  of  making  rapid  daily  changes  to  the 
schedule  also  must  be  developed.  Finally,  a  method  of  using 
the  schedule  for  forecasting  has  been  mentioned,  but  the 
method  has  yet  to  be  developed.  The  scheduling  program 
could  be  a  valuable  tool  for  forecasting  because  of  the 
ability  to  make  alternative  schedules  rapidly. 

This  research  effort  has  taken  an  initial  step  into  the 
development  of  a  DOSS  for  strategic  missile  wings.  A  con¬ 
siderable  amount  of  research  lies  ahead  before  the  idea  can 
become  a  reality.  The  results  of  the  research  are,  however, 
quite  useful  now.  The  program  can  be  applied  to  solve  sev¬ 
eral  recurring  management  scheduling  problems  in  strategic 
missi 1 e  wings. 
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APPENDIX  A 


USER" S  GUIDE 

INTRODUCTION 

This  user's  guide  is  presented  in  three  parts.  Part  I 
provides  information  to  the  user  who  is  -familiar  with  the 
scheduling  o-f  missile  combat  crews  (MCC)  but  not  proficient 
in  computer  programming.  Part  II,  on  the  other  hand, 
provides  a  detailed  explanation  of  the  programs  used  to 
input  crew  data  and  build  the  monthly  schedule,  and  assumes 
a  working  knowledge  of  both  FORTRAN  and  SLAM  programming 
procedures.  Finally,  Part  III  contains  the  program  and 
variable  listings. 


PART  I 


( 

3 

GETTING  STARTED  J 

Prior  to  using  the  crew  scheduling  program,  crew  infor¬ 
mation  must  be  assembled  into  a  -form  useable  by  the  program.  j 

Crews  numbers  should  be  assigned  in  sequence  -from  1  to  a 
maximum  of  100.  In  addition,  the  program  requires  flights 
1,  6,  and  11  to  be  the  squadron  command  posts  (SCP) .  For  | 

maximum  efficiency,  any  recrewing  actions  should  be  complete  ' 

i 

on  the  first  day  of  the  month.  Also,  reserve  or  spare  crew  ■ 

members  should  be  crewed  together  for  scheduling  purposes,  j 

when  possible.  j 

I 

The  scheduling  program  provides  for  as  many  as  three  ! 

leave  periods  for  each  crew.  Although  referred  to  as  leave 
by  the  program,  these  periods  can  be  used  to  reflect  re¬ 
quested  days  off  other  than  leave  or  crew  non-availability 
days.  These  non-availability  days  can  be  used  by  a  sched¬ 
uler  to  represent  crew  training,  such  as  upgrade  or  SCP 
training,  temporary  duty  assignments,  or  duty  not  including 
alert  (DNIA)  restrictions. 

The  training  information  required  for  the  program  in¬ 
cludes  the  number  of  different  types  of  classroom  training 
required,  the  dates  each  will  be  offered,  and  the  number  of 
Missile  Procedure  Trainer  <MPT>  sessions  per  crew.  A  maxi¬ 
mum  of  15  dates  of  offering  for  each  type  classroom  train-  j 

ing  may  be  specified.  In  addition,  the  maximum  and  minimum 
class  size  must  be  specified.  The  total  number  of  MPT  peri- 


ods  per  day  available  -for  training  must  also  be  known  before 
using  the  program. 


Finally,  an  executable  -file  of  the  program  SLMWRT  must 
be  available.  This  program  provides  an  interactive  environ¬ 
ment  for  the  scheduler  to  enter  the  monthly  requirements  for 
the  crew  scheduling  program. 

ENTERING  THE  DATA 

The  program  SLMWRT  provides  a  user  friendly  method  of 
entering  the  information  required  to  build  the  monthly 
schedule.  Once  the  information  discussed  above  is  avail¬ 
able,  simply  run  the  program  and  answer  the  questions.  In 
addition  to  the  instructions  provided  in  this  guide,  a  num¬ 
ber  of  checks  have  been  provided  in  the  program  to  decrease 
the  chances  of  entering  inconsistent  information. 

The  following  is  an  example  of  an  interactive  session 
using  the  SLMWRT  program.  Program  prompts  are  shown  in 
upper  case  and  a  typical  input  is  shown  in  lower  case. 

ENTER  DATE  <EG,  10/12/83) 

02/15/84 

ENTER  PRIORITY  FOR  CREW  FILE  <EG,  LMF<5)> 

1  vf  <  5) 

ENTER  TIE-BREAKER  PRIORITY 


lvf  <4) 


These  two  entries  shows  the  normal  priority  of  se¬ 
lecting  crews  from  the  eligible  for  alert  (EA>  queue.  The 
first  entry  means  the  crew  with  the  fewest  number  of  alerts 
(attribute  5)  will  be  selected  first.  The  tie-breaker  rule 
specifies  that  if  two  crews  have  the  same  number  of  alerts 
then  select  the  crew  with  the  smallest  value  for  crew  type 
(attribute  4)  first.  Other  possible  priorities  are  low 
value  first,  LVF,  or  high  value  first,  HVF,  on  any  attri¬ 
bute,  last  in  first  out,  LIFO,  and  first  in  first  out,  FIFO 

ENTER  NUMBER  OF  DAYS  IN  THE  MONTH 
36 


These  questions  provide  the  information  necessary  to 
construct  the  model  used  in  simulating  a  month  of  alert 
duty.  The  next  questions  are  used  to  elicit  information 
concerning  each  crew  and  the  monthly  training  data. 

ENTER  NUMBER  OF  CREWS 
90 

Enter  the  total  number  of  crews,  including  line, 


flight  commander,  DOV/DOT,  and  any  crews  formed  from  spare 
or  reserve  crew  members.  The  program  is  designed  to  handle 


FIRST  FIFTEEN  ENTRIES  SENT  ON  ALERT  FOR  DAY  1 


ENTRY  NUMBER  1 

ENTER  CREW  NUMBER,  FLIGHT,  SCP  QUAL,  AND  TYPE 
5  110 

After  printing  the  reminder  that  the  first  fifteen  en 
tries  are  immediately  sent  on  alert,  the  entry  number  is 
printed  and  information  for- each  crew  is  requested.  The 
above  entry  indicates  crew  number  5  is  assigned  to  flight  1 
and  is  an  SCP  qualified  line  crew.  Acceptable  values  for 
the  requested  parameters  are  as  follows: 


Crew  number  1-100 

Flight  1-17 

SCP  Qualification: 

Qual if ied  1 

Not  Qualified  0 
Crew  Type: 

Line  0 

FI t  CC  1 

DOV/DOT  2 


Data  entered  outside  of  these  ranges  will  result  in  a 
warning  message  followed  by  another  request  for  the  data  in 
question . 

HOW  MANY  LEAVE  PERIODS  REQUESTED  <0-3> 


If  '9'  is  entered  the  program  will  move  to  the  next 

crew. 

ENTER  START  AND  END  LEAVE  DATES,  PERIOD  1 
16  15 

ENTER  NUMBER  OF  ACTUAL  LEAVE  DAYS  FOR  CREW  5 
6 

The  above  entries  indicate  crew  five  has  requested 
leave  from  the  tenth  to  the  fifteenth  of  the  month.  If  the 
actual  number  of  leave  days  was  less  than  six,  this  would 
indicate  a  non-leave  unavailability  of  the  crew.  If  more 
than  one  leave  is  requested  the  start  and  end  leave  date 
requests  would  appear  the  appropriate  number  of  times.  The 
actual  number  of  leave  days  request  is  not  printed  until  all 
leave  dates  have  been  entered. 

If  the  end  leave  date  is  earlier  than  the  start  leave 
date  a  warning  will  be  printed  followed  by  a  re-entry  re¬ 
quest  for  the  information.  One  day  requests  are  input  by 
entering  the  day  twice  as  both  the  start  and  end  leave  date. 
In  addition,  for  leaves  involving  more  than  one  month,  only 
the  current  month  dates  are  entered.  After  the  leave  data 
is  entered  the  program  will  proceed  to  the  next  crew  entry. 

Once  all  crew  information  has  been  input,  the  program 
will  request  training  information. 


ENTER  THE  NUMBER  OF  CLASSROOM  TYPE  TRAINING  <1,2,3) 
2 

ENTER  TRAINING  CODE  FOR  TYPE  1 
33 

ENTER  MAXIMUM  AND  MINIMUM  CLASS  CLASS  SIZE 
15  6 

ENTER  TRAINING  DAY  FOR  TYPE  1 
7 

These  entries  illustrate  a  normal  number  of  required 
classroom  training  types.  For  example,  emergency  Mar  order 
(ENO)  and  codes  training  are  taught  on  the  same  day  and 
weapon  system  training  is  taught  by  itself.  The  requested 
training  code  is  a  2-digit  numeric  code  to  identify  the  as¬ 
signed  training  day  on  the  schedule.  Because  of  prior  use, 
numbers  1-15  <LCC  identifiers) ,  66  <MPT  identifier) ,  77 
(leave  identifier),  and  99  (alert  return  day  identifier) 
should  not  be  used.  The  maximum  and  minimum  class  size  is 
sel f-expl anatory ,  however ,  the  maximum  class  size  allowed  by 
the  program  is  25  crews.  The  training  day  request  will  be 
repeated  15  times  to  allow  up  to  15  possible  days  for  con¬ 
ducting  the  training.  If  less  than  15  possible  training 
days  are  desired,  enter  "0'  to  the  additional  program 


requests. 

Following  the  15  requests  -for  training  dates,  the 
program  will  ask  the  same  questions  -for  the  next  classroom 
type  training. 

ENTER  NUMBER  OF  MPT  PERIODS  PER  CREW  <1  OR  2) 

2 

If  the  number  of  MPT  periods  per  crew  is  '1',  the  next 
question  will  not  be  presented. 

ENTER  MINIMUM  TIME  BETWEEN  MPT  PERIODS 

5 

ENTER  NUMBER  OF  MPT  PERIODS  PER  DAY 

DAY  1 

6 


DAY  38 
8 

The  minimum  time  between  MPT  sessions  is  used  to  sep¬ 
arate  MPT  training  when  more  than  one  session  is  scheduled. 
The  number  of  MPT  periods  for  each  day  should  reflect  the 
total  number  of  MPT  periods  available  for  training.  Crews 


will  be  assigned  -for  MPT  training  up  to  the  maximum  number 
of  periods  available  on  that  day.  The  actual  times  for  each 
session  will  have  to  be  manually  determined  by  the  sched¬ 
uler. 


ENTER  MAXIMUM  NUMBER  OF  ALERTS  FOR: 

LINE  CREWS,  FLIGHT  COMMANDERS ,  AND  DOV/DOT 
8  4  2 


Simply  enter  the  maximum  number  of  alerts  for  each 
crew  type.  Although  the  response  listed  above  is  the  normal 
setting,  in  times  of  restricted  crew  availability  higher 
numbers  may  be  desirable. 


ENTER  PERCENTAGES  FOR  ALERT  ASSIGNMENTS: 

FOR  NON-SCP  ALERTS  —  DOV/DOT,  FLT  CC,  INTEGRAL 
.17  .57  .97 


FOR  SCP  ALERTS  —  DOW/DOT,  INTEGRAL 


.3  .8 


These  percentages  are  used  to  search  for  a  specific 
crew  for  alert  based  on  the  comparison  of  a  random  number 
between  zero  and  one  and  these  percentages.  The  response 
indicates  that  on  the  average  a  DOV/DOf  crew  will  be  sent  to 
a  non-SCP  17  percent  of  the  time,  a  flight  commander  will  be 
sent  on  alert  40  percent  <.57-. 17)  of  the  time,  and  a  crew 


will  be  sent  to  their  home  LCC  40  percent  <.?7-.57>  of  the 


time.  If  the  search  for  a  particular  crew  is  unsuccessful, 
another  crew  will  be  found  by  first  checking  available  line 
crews  based  on  the  EA  queue  priority  discussed  earlier.  If 
this  search  is  unsuccessful  than  the  first  available  crew  of 
any  type  will  be  assigned.  The  percentages  specified  for 
SCP  alerts  provide  the  same  type  of  searches,  however,  only 
SCP  qualified  crews  are  considered.  These  setting  also  help 
distribute  DOV/DOT  and  flight  commander  alerts  throughout 
the  month.  Experimentation  has  shown  the  following  settings 
provide  the  best  results:  for  non-SCP  alerts,  .1  .2  1.  or 
.20.  1.  for  DCW/DOT,  flight  commander,  and  integral  per¬ 
centages,  respectively.  For  SCP  alerts  the  settings  are:  .2 
1.  or  .1  1.  for  DOV/DOT  and  integral  percentages,  respec¬ 
tively. 

ENTER  THE  2  RANDOM  NUMBER  STREAMS  C1-I0) 

1  2 


The  program  allows  specification  of  the  number  stream 
used  to  seed  the  random  numbers  used  in  the  non-SCP  and  SCP 
alert  selection  process.  Ten  streams  are  available  and  any 
combination  may  be  used.  By  running  the  scheduling  program 
with  different  streams  slightly  different  schedules  will 
resul t . 

This  completes  the  entry  of  data  necessary  for  the  crew 
scheduling  program.  A  file  named  SLAMIN  is  created  by  the 


A- 10 
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program  and  contains  the  data  entered  by  the  scheduler. 

This  -file  should  now  be  saved  -for  use  with  the  crew 
scheduling  program. 

RUNNING  THE  PROGRAM 

The  actual  procedures  -for  running  the  crew  scheduling 
program  are  both  machine  and  installation  dependent  and  will 
not  be  discussed  here.  However,  the  following  general  guid¬ 
ance  is  provided  to  assist  the  scheduler  in  producing  a  high 
quality  schedule. 

Once  the  data  file  has  been  created  a  number  of  program 
runs  should  be  made  with  different  seeds.  The  scheduler  can 
then  compare  the  schedules  and  choose  the  the  most  appropri¬ 
ate.  In  addition,  alternate  schedules  can  be  produced  by 
varying  training  dates,  MPTs  and  leave  requests. 

If  the  program  consistently  provides  a  schedule  with  a 
number  of  alerts  unfilled,  the  maximum  alert  parameters 
should  be  changed.  Once  these  changes  are  made,  additional 
program  runs  can  be  made  to  find  a  feasible  schedule. 


PART  II 


PROGRAM  EXPLANATION;  SLhWRT 

As  discussed  in  Part  I  of  this  guide,  the  SLMWRT  program 
is  designed  to  provide  a  user  -friendly  interface  to  the  SLAM 
crew  scheduling  program.  It  is  interactive  and  consists  of 
only  a  main  program.  The  program  provides  two  key  types  of 
information  to  the  crew  scheduling  program.  First,  the  pro¬ 
gram  actually  writes  the  SLAM  control  cards  to  the  file 
SLAMIN.  Immediately  following  these  control  cards,  the  crew 
and  training  data  is  written  to  the  same  file. 

The  SLAM  control  cards  are  used  to  provide  information 
concerning  project  description,  number  of  files  used,  number 
of  attributes  per  transaction,  number  of  concurrent  trans¬ 
actions,  queue  priorities  and  initial  status.  In  addition, 
the  control  cards  describe  the  network  used  to  simulate  the 
crew  alert  system.  The  network  diagram  for  this  system  is 
contained  in  Figure  A-l  and  the  SLAM  control  cards  are 
listed  in  Part  III  of  this  guide. 

The  network  consists  of  15  identical  queueing  systems. 
These  queues  and  their  accompanying  service  activities 
represent  the  15  launch  control  centers  <LCC>  of  a  three- 
squadron  wing.  Entry  to  the  system  occurs  at  each  labeled 
queue  node  and  a  transaction  representing  the  crew  is  then 
sent  to  the  service  activity  to  simulate  a  24-hr  alert.  At 
alert  completion  the  crew  transaction  enters  the  event  node 
to  determine  the  completing  crew's  disposition  and  triggers 


a  search  -for  the  next  day's  alert  crew.  These  actions  occur 
when  the  event  node  transfers  control  to  the  event  subrou¬ 
tine  of  the  crew  scheduling  program.  The  terminate  node  is 
then  used  to  destroy  the  completed  crew  transaction. 

The  SLMWRT  program  allows  the  user  to  specify  the  date 
of  the  run  for  identification,  the  crew  file  queueing  disci¬ 
pline,  and  the  number  of  days  in  the  month.  Using  this  in¬ 
formation  the  SLAM  control  cards,  including  the  network 
cards,  are  written  to  the  input  file.  The  network  is  writ¬ 
ten  using  a  simple  loop  structure  which  stores  the  queue 
labels  in  the  character  array,  QUEUE. 

The  remainder  of  the  program  is  used  to  gather  informa¬ 
tion  on  the  individual  crews  and  training  requirements.  The 
format  consists  of  a  straight  forward  question  and  answer 
session  followed  by  writing  the  information  to  the  input 
file.  To  decrease  problems  associated  with  incorrect  input 
data,  the  SLMWRT  program  checks  most  information  for  cor¬ 
rectness  and  consistentcy.  For  incorrect  information,  a 
warning  is  printed  and  the  user  is  allowed  to  reenter  the 
information.  A  complete  listing  of  this  program  is  included 
in  Part  III  of  this  guide. 

PROGRAM  EXPLANATION:  CREW  SCHEDULING  PROGRAM 

The  crew  scheduling  program  uses  a  combined  network  and 
discrete  event  approach  to  the  problem  of  scheduling  crews 
for  alert.  The  FORTRAN  program  consisting  of  a  main  program 
and  ten  subroutines  provides  the  logic  for  the  interaction 


of  the  network  and  discrete  event  portions  of  the  model 
This  program  will  be  described  below. 


Proor am  MAIN 

The  main  program  is  the  standard  version  used  by  SLAM  to 
dimension  the  SLAM  arrays  and  establish  input  and  output 
device  numbers.  From  the  main  program  the  SLAM  subroutine 
is  called  to  control  the  execution  o-f  the  simulation. 


Subroutine  INTLC 

The  INTLC  subroutine  is  used  to  initialize  user  varia¬ 
bles  and  read  crew,  training,  and  other  scheduling  informa¬ 
tion  from  the  input  file  created  by  the  SLMWRT  program. 

Named  common  blocks  are  used  to  transfer  this  information  to 
the  other  subroutines  in  the  program.  Once  the  INTLC  sub¬ 
routine  is  complete,  the  crew  scheduling  function  begins. 

An  important  array  initialized  in  this  subroutine  is  the 
array  DUMMY.  This  array  will  be  used  whenever  it  is  neces¬ 
sary  to  place  an  event  on  the  calendar  that  does  not  pertain 
to  a  specific  crew.  An  array  such  as  DUMMY  is  needed  as  a 
place  holder  in  the  call  statement  of  some  SLAM  subroutines. 
Specific  uses  of  array  DUMMY  will  be  pointed  out  when  they 
occur . 

After  initializing  user  variables  and  arrays,  subroutine 
INTLC  begins  to  read  the  crew  information  from  the  input 
file.  This  identifying  crew  information  is  stored  as  SLAM 


ATTRIBUTE 


1 

2 

3 

4 

5 

6 
7 
3 
9 

10 

11 

12 


SLAM  ATTRIBUTES 

DESCRIPTION 

Crew  Number  —  must  begin  at  1  and  continue 
sequentially  to  a  maximum  of  100 

Flight  Designator  —  1  thru  15,  16=D0T,  17=D0V 

SCP  Designator  —  0=Not  quali-fied,  l=Qua1ified 

Crew  Type  —  0=Line,  1=F1 ight  CC,  2=D0U/D0T 

Number  of  Alerts  —  Total  number  of  alerts  in 
a  month 

Spare 

LV1  Starting  Date 
LV1  Ending  Date 
L<J2  Starting  Date 
LV2  Ending  Date 
LV3  Starting  Date 
LV3  Ending  Date 


Figure  A-2.  Crew  Attributes 


attributes  (Figure  A-2>  .  The  total  number  of  crews  is  read, 
followed  by  the  first  loop  used  to  enter  crew  information. 
This  loop  reads  the  first  fifteen  crews  and  sequentially 
places  one  crew  in  each  of  the  fifteen  queues  used  to  simu¬ 
late  alerts.  These  are  the  crews  performing  alert  on  the 
first  day  of  the  month.  In  addition,  flight  assignment  data 


is  copied  from  attribute  2  to  build  the  INTFLT  array  and  the 
actual  number  of  leave  days  requested  by  the  crew  is  loaded 


into  the  LVDAYS  array.  Both  of  these  arrays  are  indexed  by 
crew  number.  The  INTFLT  array  will  be  used  in  the  statis¬ 
tics  gathering  subroutine  to  differentiate  between  line 
crews  <coded  with  numerical  flight  assignment,  i-15) ,  flight 
commanders  (coded  with  the  negative  of  flight  assignment, 
-l-<-15)>,  and  DOV/DOT  crews  (coded  as  16  and  1 7> .  The 
LVDAYS  array  is  also  used  in  the  statistics  subroutine  to 
account  for  actual  leave  days  as  free  days. 

The  second  loop  used  to  enter  crew  information  reads  the 
data  for  all  crews  not  performing  alert  on  the  first  day  of 
the  month.  In  addition  to  building  the  INTFLT  and  LVDAYS 
arrays  as  discussed  above,  this  loop  also  checks  for  any 
crew  with  leave  beginning  on  the  first  day  of  the  month. 
Crews  with  leave  beginning  on  the  first  of  the  month  are 
placed  on  the  event  calendar  with  a  return  event  scheduled 
upon  completion  of  their  leave.  The  crew  scheduling  array, 
ISCHED,  is  also  updated  with  the  leave  information.  All 
other  crews  are  placed  in  the  eligible  for  alert  (EA)  queue, 
FILE  16.  A  listing  of  all  files  used  by  the  program  is  in 
Figure  A-3. 

Following  the  individual  crew  information,  the  crew 
training  data  is  read.  Possible  training  dates  for  each 
type  classroom  training  is  placed  in  array  ITRNDY(i,j>, 
where  i  refers  to  the  type  training  and  j  refers  to  the  date 
index.  The  numeric  code  for  the  training  is  placed  in  array 
MRKDAY  and  the  maximum  and  minimum  allowed  class  size  is 
stored  in  the  arrays  MAXCLS  and  MINCLS.  The  number  of  MPT 


SLAM  FILES 


FILE  DESCRIPTION 

1-15  Alert  Files  —  Represents  alert  LCCs 

16  Crew  File  —  Eligible  for  alert  <EA>  queue 

17  Inactive  Crew  File  —  contains  line  crews  who  have 
completed  their  maximum  number  o-f  alerts 

18  Inactive  Crew  File  —  contains  DOV/DOT  crews  who 
have  completed  their  maximum  number  o-f  alerts 

19  Inactive  Crew  File  —  contains  -flight  commander 
crews  who  have  completed  their  maximum  number  of 
al er ts 

28  Spare 


Figure  A-3.  SLAM  File  Description. 

sessions  requested  per  crew  is  read  into  variable  NUMMPT  and 
the  number  of  MPT  training  periods  available  each  day  of  tne 
month  is  stored  in  array  MPTDAY.  In  addition,  if  more  than 
one  MPT  per  month  is  requested  the  variable  for  specifying 
the  minimum  number  of  days  between  MPT  training  <MTBMPT>  is 
read. 

Finally,  general  information  needed  for  the  scheduling 
program  is  read  from  the  input  file.  This  includes  the 
maximum  number  of  alerts  allowed  for  each  crew  type  (MAXLIN, 
MAXSHP,  MAXFCC) ,  the  internal  percentages  used  in  deter¬ 
mining  selection  of  crews  for  alert  <SHPPCT,  FCCPCT,  FLTPCT, 
SHPCTS,  FTPCTS) ,  and  the  SLAM  random  number  seed  streams 
<  I STRM 1 ,  ISTRM2). 
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The  INTLC  subroutine  also  establishes  the  time  for 
checking  crew  leave  requests.  This  is  done  by  placing  an 
event  on  the  calendar  to  trigger  a  call  to  the  leave  sub¬ 
routine.  Since  this  event  involves  no  specific  crew,  the 
array  DUMMY  is  used  in  the  call  statement. 

Subroutine  EVENT <  IFN) 

This  subroutine  is  used  to  direct  program  flow  in  the 
discrete  event  portion  of  the  simulation.  Arriving  trans¬ 
actions  carry  a  code,  IFN,  used  to  control  their  disposi¬ 
tion.  Transactions  can  enter  this  subroutine  from  the 
network  portion  of  the  model  through  the  EVENT  nodes  or  from 
the  event  calendar.  Normally  these  transactions  represent 
crews  processing  through  the  model .  Dummy  transactions, 
however,  are  also  used  to  trigger  other  activities. 

As  each  transaction  arrives,  the  current  simulation  day 
<IDAY>  and  next  day  (NXTDAY)  are  recorded.  In  addition,  the 
variable  IFILE  is  set  equal  to  IFN  for  transfer  to  other 
subroutines.  IFILE  identifies  the  queue  (LCC)  where  an 
alert  was  just  completed  for  crew  transactions.  Next  the 
transaction  is  checked  to  determine  its  disposition. 

An  IFN  of  25  indicates  a  crew  transaction  has  arrived 
from  the  event  calendar.  This  indicates  the  crew  has  either 
just  returned  from  leave  status  or  has  just  completed  crew 
rest  requirements.  In  either  case,  the  crew  is  placed  back 
in  the  EA  queue  and  no  further  subroutine  action  is  re¬ 
quired. 
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An  IFN  equal  to  30  indicates  a  non-crew  transaction  from 
the  event  calendar.  This  code  is  used  to  schedule  the  daily 
leave  request  check  prior  to  scheduling  the  next  day's 
alerts.  Following  the  leave  check  control  is  returned  to 
the  SLAM  processor. 

The  last  special  case  which  must  be  considered  is  the 
arrival  of  a  dummy  crew  transaction.  This  transaction  is 
necessary  to  initiate  a  search  for  the  next  alert  crew  when 
the  previous  day's  alert  could  not  be  filled  for  some  spe¬ 
cific  LCC.  In  this  case  IFILE  identifies  the  LCC  and  a  crew 
number  of  zero  identifies  the  dummy  transaction.  Mhen  the 
dummy  transaction  arrives  it  is  immediately  transferred  to 
the  computed  GOTO  for  routing  to  the  appropriate  next  alert 
subroutine. 

All  other  transactions  represent  crews  completing  an 
alert.  These  transactions  are  input  from  the  EVENT  nodes  of 
the  network  and  identify  the  LCC  where  the  alert  was  per¬ 
formed  by  IFILE.  First,  the  crew  scheduling  array,  ISCHED, 
is  updated  with  the  completed  alert  location  and  day  of 
return  code.  In  addition,  the  number  of  alerts  is  increased 
by  adding  one  to  attribute  5. 

Next  the  crew  is  checked  to  determine  if  the  maximum 
number  of  alerts  have  been  completed  for  the  month.  If  this 
is  true,  then  subroutine  LVUPDT  is  called.  The  purpose  of 
this  subroutine  will  be  discussed  later.  Upon  return  from 
LVUPDT  the  crew  is  placed  in  the  appropriate  inactive  file, 


however,  the  transaction  continues  to  flow  through  the  EVENT 


subroutine  to  trigger  a  search  -for  the  next  day's  alert 
crew. 

If  the  maximum  number  of  alerts  has  not  been  reached, 
the  crew  is  checked  for  leave  requests  scheduled  to  start 
within  the  normal  crew  rest  period.  If  a  leave  request  is 
found,  the  crew  schedule  is  updated  and  the  crew  is  placed 
on  the  calendar  to  return  on  leave  completion.  This  leave 
check  immediately  after  an  alert  precludes  the  LEAVE  sub¬ 
routine  from  checking  the  event  calendar  for  crews  in  crew 
rest  status  with  concurrent  leave  requests.  Again,  the 
transaction  also  continues  through  the  EVENT  subroutine  to 
trigger  a  search  for  the  next  day's  alert  crew. 

If  no  leave  is  requested  within  two  days  of  the  alert, 
the  crew  is  placed  on  the  event  calendar  to  return  following 
crew  rest.  A  1.5-day  delay  is  used  to  simulate  the  day  of 
return  from  alert  and  the  day  of  crew  rest.  This  delay  in¬ 
sures  that  a  crew  will  not  be  selected  for  a  "back-to-back* 
al  er t . 

Finally,  the  crew  transaction  is  used  to  trigger  the 
search  for  the  next  day's  alert  crew  for  each  LCC.  A 
computed  GO  TO  statement  is  used  to  call  the  appropriate 
next  event  subroutine.  This  call  is  based  on  the  location 
of  the  completed  alert. 


The  NXTALT  subroutine  is  used  to  select  the  next  alert 
crew  for  non-SCP  launch  control  centers  <LCC> .  Crews  are 


selected  by  searching  the  EA  queue  (FILE  16)  based  on  the 
priority  ranking  in  the  queue  and  the  specified  alert  per¬ 
centages.  Following  their  selection,  the  crew  is  sent  to 
the  alert  (queue)  specified  by  IFILE. 

Before  attempting  a  crew  search,  the  EA  queue  is  checked 
to  determine  if  any  crews  are  available  for  alert  duty.  The 
variable  NEXT  is  set  equal  to  the  pointer  which  identifies 
the  first  crew  in  the  EA  queue.  If  NEXT  equals  zero  the 
queue  is  empty  and  a  warning  message  is  provided.  In  addi¬ 
tion  to  the  warning,  a  dummy  transaction  is  placed  on  the 
event  calendar  to  insure  subsequent  attempts  to  find  an 
alert  crew  for  that  LCC. 

If  at  least  one  crew  is  available  for  alert,  the  search 
begins  by  drawing  a  random  number  (RN)  between  zero  and  one. 
If  RN  is  less  than  or  equal  to  one  of  the  specified  percent¬ 
ages  the  search  will  proceed  for  the  crew  matching  the  re¬ 
quired  attribute(s) .  The  first  crew  found  to  match  these 
requirements  will  be  removed  from  the  EA  queue  and  sent  to 
the  alert  queue  specified  by  IFILE.  If  no  crew  matching  the 
attribute(s)  is  found,  another  search  will  be  initiated  to 
select  the  first  line  crew  available.  Finally,  if  this 
search  fails,  the  first  crew  of  any  type  will  be  selected. 

In  all  these  searches,  the  first  crew  is  determined  by  the 
priority  ranking  specified  for  the  EA  queue. 

The  searches  are  implemented  by  a  repeat  until  type 
structure.  Specifically,  as  each  crew  in  the  EA  queue  is 
checked  the  variable  NEXT  is  set  equal  to  the  pointer  of  the 


next  crew  in  the  file.  If  the  correct  crew  is  found  then 
the  search  wilt  stop,  otherwise  the  search  wilt  continue 
until  NEXT  is  equal  to  zero  indicating  all  crews  in  the  file 
have  been  checked. 

The  purpose  of  the  alert  selection  percentages  are  to 
help  spread  the  DOV/DOT  and  flight  commander  alerts  through¬ 
out  the  month  and  to  control  the  number  of  integral  alerts. 
The  goal  of  distributing  these  alerts  throughout  the  month 
is  also  assisted  by  searching  for  a  line  crew  when  the  ini¬ 
tial  search  fails. 


Subroutine  NXTSCP 

The  NXTSCP  subroutine  provides  the  same  function  as  the 
NXTALT  subroutine  but  for  SCP  only  alerts.  The  explanation 
of  NXTALT  applies  to  NXTSCP  with  the  following  exceptions. 
First,  any  crew  selected  must  be  SCP  qualified  (attribute  3 
=  1) .  Second,  if  the  first  search  is  unsuccessful ,  the  next 
search  will  choose  the  first  available  SCP  crew  of  any  type. 
Finally,  although  other  crews  may  be  available,  a  warning 
message  will  be  provided  when  an  SCP  qualified  crew  is  not 
available  for  an  SCP  alert. 


Subroutine  LEAVE 

The  LEAVE  subroutine  is  used  to  remove  crews  from  the  EA 


queue  for  their  requested  periods  of  leave.  The  subroutine 
also  updates  the  crew  schedule  with  the  leave  code,  77,  for 


each  day  o-f  leave.  Crews  removed  -from  the  EA  queue  are 
placed  on  the  event  calendar  for  the  duration  of  their  leave 
and  return  to  the  EA  queue  at  leave  completion. 

The  subroutine  begins  by  scheduling  the  next  leave  check 
to  occur  one  day  later.  Since  the  first  leave  check  occurs 
at  .8  days,  the  remaining  checks  are  made  at  day  1.8,  2.8, 
etc.  Using  this  method,  leave  requests  are  reviewed  prior 
to  determining  the  next  day's  alert  crews. 

The  same  basic  search  structure  is  used  as  in  the  next 
alert  subroutines.  The  first  crew's  leave  requests  are 
copied  into  the  LVBEG  and  LVEND  arrays.  These  values  are 
then  checked  to  determine  if  leave  is  scheduled  to  start 
within  the  next  two  days.  If  leave  is  to  start  within  this 
time,  the  crew  schedule  is  updated  and  the  duration  of  leave 
is  determined  for  event  calendar  timing.  The  crew  is  then 
removed  from  the  EA  queue  and  placed  on  the  event  calendar 
with  a  return  scheduled  when  the  leave  is  completed.  To 
preserve  the  pointer  to  the  next  crew  in  the  EA  queue,  the 
variable  MOVE  is  used  to  temporarily  hold  the  next  crew's 
position  prior  to  removing  the  leave  crew.  Mhen  the  trans¬ 
fer  to  the  event  calendar  is  complete,  NEXT  is  set  equal  to 
MOVE  and  the  search  continues  until  all  crews  in  the  EA 
queue  have  been  checked. 


Subroutine  LVUPDT 

Since  the  LEAVE  subroutine  only  searches  the  EA  queue, 
only  active  crews  are  checked  for  leave  requirements.  The 
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LUUPDT  subroutine  is  used  to  check  crews  who  have  reached 


the  maximum  number  o-f  alerts  and  are  about  to  be  placed  in 
an  inactive  status.  Because  these  crews  have  completed 
their  alert  requirements  -for  the  month,  only  the  crew  sched¬ 
ule  must  be  updated. 

The  LL*BEG  and  LL*END  arrays  are  again  used  to  hold  leave 
in-formation.  A  simple  loop  is  then  used  to  check  i-f  any 
leave  is  scheduled  a-fter  the  current  day.  I-f  leave  is 
found,  then  the  crew  schedule  is  updated  to  reflect  this 
1 eave . 


Subroutine  OTPUT 

The  calling  of  the  OTPUT  subroutine  by  the  SLAM  proces¬ 
sor  signals  the  completion  of  the  crew  alert  scheduling 
simulation.  At  this  point  leave  and  alert  requirements  for 
the  month  are  complete  and  reflected  in  the  crew  schedule, 
ISCHED.  The  OTPUT  subroutine  now  calls  the  subroutines  to 
schedule  all  training  requirements  and  gather  statistics  on 
the  monthly  schedule. 

Once  all  training  has  been  scheduled  and  statistics  com 
puted,  OTPUT  will  print  thp  crew  scheduling  array.  The 
codes  used  in  the  scheduling  array  are  listed  in  Figure  A-4 
To  accommodate  the  different  month  lengths,  a  variable  for¬ 
mat  structure  is  used.  This  variable  formatting  is  accom¬ 
plished  using  a  character  array  (FORMAT)  to  store  the  dif¬ 
ferent  possibilities  and  the  character  variable  FMT 1 . 

Next,  the  statistical  data  for  the  month  is  printed. 
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SCHEDULE  CODES 


Ac  t i vi tv 

Code 

Alerts 

1-15 

Return  Day 

99 

Leave 

77 

MPT  Session 

66 

Cl assroom 
Training 

XX 

XX  —  User  Supplied  Code 


Figure  A-4.  Crew  Schedule  Codes 


First,  information  on  the  number  of  alerts,  integral  alerts, 
free  days,  and  actual  leave  days  is  printed  for  each  crew. 
Cumulative  mean  and  standard  deviation  statistics  are  then 
printed  for  line  crews  covering  the  number  of  alerts,  inte¬ 
gral  alerts,  and  free  days. 


Subroutine  TRNING 

Subroutine  TRNING  assigns  crews  to  classroom  training 
requirements.  Up  to  three  types  of  classroom  training  can 
be  accommodated.  In  addition,  each  type  training  can  be  of¬ 
fered  on  a  maximum  of  15  days  and  the  maximum  (up  to  25 
crews)  and  minimum  (1  crew)  class  sizes  can  be  different  for 
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each  type  training.  Finally,  a  warning  is  printed  -for  any 
crew  not  scheduled  -for  a  particular  type  o-f  training  and  a 
recap  o-f  the  actual  class  days  and  class  sizes  is  provided. 

Three  subroutine  peculiar  arrays  are  needed  in  TRNING. 
Array  I  COUNT  stores  the  number  of  crews  scheduled  for  each 
possible  training  day.  Logical  array  NOSCHD  keeps  track  of 
whether  a  crew  has  been  scheduled  for  training  or  not.  In 
NOSCHED  .TRUE,  indicates  the  crew  has  not  been  scheduled  for 
training.  Finally,  array  ICREW  holds  the  crew  numbers  of 
crews  selected  for  training  on  the  first  pass  on  a  given 
training  day. 

The  subroutine  assigns  crews  using  a  two  pass  system. 

On  the  first  pass  up  to  80  percent  of  the  maximum  class  size 
is  scheduled.  If  it  was  not  possible  to  schedule  80  percent 
of  the  maximum  class  size,  but  the  number  of  crews  available 
was  equal  to  at  least  the  minimum  class  size,  then  these 
crews  are  scheduled.  If  neither  of  these  conditions  are 
satisfied,  then  no  crews  are  scheduled  for  that  day  and  the 
subroutine  moves  to  the  next  training  day.  This  process 
continues  until  all  training  days  are  considered. 

The  actual  scheduling  of  crews  for  classroom  training  is 
accomplished  by  updating  the  crew  scheduling  array  with  the 
appropriate  training  code  <MRKDAY> .  In  addition,  .TRUE,  en¬ 
tries  are  changed  to  .FALSE,  for  all  scheduled  crews  in 
array  NOSCHD. 

Next  the  second  pass  for  assigning  crews  to  classroom 
training  is  accomplished.  Training  days  previously  sched- 


uled  are  now  -filled  up  to  the  maximum  allowed  class  size. 

As  crews  are  scheduled,  the  crew  scheduling  array,  ISCHED, 
and  the  NOSCHD  array  are  updated.  Using  the  data  contained 
in  NOSCHD,  any  crew  not  scheduled  -for  training  is  reported 
to  the  user. 

Finally,  a  recap  o-f  the  type  classroom  training  sched¬ 
uled  is  provided.  This  recap  includes  the  type  training 
{identified  by  the  MRKDAY  code),  training  date,  and  number 
crews  assigned  on  that  day.  Additional  cal  l~s  are  then  made 
to  this  subroutine  for  each  type  classroom  training  re¬ 
quested. 

Subroutine  MPTTRN 

The  MPTTRN  subroutine  is  used  to  schedule  either  one  or 
two  MPT  sessions  per  crew.  When  more  than  one  MPT  session 
is  requested,  a  minimum  time  between  training  sessions  is 
specified  to  preclude  back  to  back  MPT  training.  All  crews 
are  considered  for  the  MPT  sessions  and  crews  not  assigned 
are  reported  to  the  user. 

The  arrays  MPTSCH<i,j)  and  NOASGN  are  peculiar  to  this 
subroutine.  MPTSCH<i,j>  is  used  to  store  the  MPT  session 
date  for  each  crew,  i,  and  each  MPT  session  number,  j  < 1  or 
2).  The  MPT  session  date  is  important  when  scheduling  more 
than  one  training  session  to  determine  if  the  minimum  time 
between  MPTs  <MTBMPT)  requirement  is  satisfied.  The  array 
NOASGN  simply  keeps  track  of  the  number  of  MPT  sessions 
assigned  on  each  day.  This  number  is  then  compared  to  the 


number  of  sessions  available  in  MPT DAY  to  prevent  over 
schedu ling. 


The  subroutine  considers  each  crew  by  searching  the 
entire  month  o-f  available  MPT  sessions  be-fore  moving  to  the 
next  crew.  If  an  available  period  is  found  the  crew  is 
scheduled  by  updating  the  crew  schedule  and  the  MPTSCH  ar¬ 
ray.  In  addition,  if  more  than  one  MPT  session  was  speci¬ 
fied,  only  MPT  sessions  meeting  the  MTBMPT  criteria  will  be 
scheduled  for  the  second  session.  All  crews  are  checked  for 
first  session  availability  before  moving  to  the  second  ses¬ 
sion  request. 

Any  crews  not  scheduled  for  MPT  training  are  reported  to 
the  user.  Crews  are  reported  by  both  crew  number  and  which 
MPT  session  could  not  be  scheduled.  The  conclusion  of  the 
MPTTRN  subroutine  signals  the  completion  of  all  crew  sched¬ 
uling  activi ties. 


Subroutine  STATS 

The  STATS  subroutine  is  used  to  collect  individual  crew 
and  cumulative  line  crew  data  from  the  monthly  schedule. 

The  information  is  taken  from  the  crew  scheduling  array, 
ISCHED,  which  now  contains  all  monthly  requirements. 

First  the  subroutine  loops  through  the  schedule  collect¬ 
ing  information  on  each  crew.  This  information  includes  the 
number  of  alerts,  number  of  integral  alerts,  and  number  of 
free  days  which  includes  the  number  of  actual  leave  days. 


Next,  a  second  looping  is  used  to  accumulate  data  on 
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PROGRAM  LISTING:  SLWRT 


PROGRAM  SLMWRT 
C 

C  XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 
C  X  THIS  PROGRAM  PROVIDES  A  USER  FRIEND-  X 

C  X  LY  METHOD  OF  CREATING  THE  DATA  FILE  X 

C  X  REQUIRED  BY  THE  SLAM  CREW  SCHEDULING  X 

C  X  PROGRAM.  BY  RESPONDING  TO  PROGRrf*!  X 

C  X  PROMPTS,  THE  USER  SPECIFIES  INFORMA-  X 

C  X  T I ON  FOR  THE  SLAM  CONTROL  CARDS,  X 

C  X  INDIVIDUAL  CREW  ATTRIBUTES  AND  X 

C  X  TRAINING  REQUIREMENTS.  THIS  DATA  IS  X 

C  X  THEN  WRITTEN  TO  THE  FILE  'SLAMIN'  X 

C  X  FOR  USE  WITH  THE  SLAM  CREW  SCHEDULINGX 

C  X  PROGRAM.  FOR  MORE  DETAILED  INFORMA-  X 

C  X  TION,  PLEASE  REFER  TO  THE  USER  GUIDE.X 

C  XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 

C 

CHARACTER  QUEUE< 15) X4,PRI01X6,PRI02X6,DATEX8 

DIMENSION  STRTLV(3) ,ENDLV<3) , ITRNDY(3, 15) ,MPTDAY(31) , ITYPE<3) ,MRKD 
1 AY  <  3) ,MAXCLS<3) ,MINCLS<3) 

C 

C  INITIALIZE  ARRAY  'QUEUE'  WITH  NAMES 

C  REPRESENTING  EACH  LAUNCH  CONTROL  CENTER 

C 

DATA  QUEUE/' ALFA' , ' BRAV' , ' CHAR' , ' DELT' , ' ECHO' , ' FOXT ' , ' GOLF ' , ' HOTE' 
1 , ' INDI ' , ' JULI ' , 'KILO' , 'LIMA' , 'MIKE' , 'NOVE' , 'OSCA'/ 

C 

C  PROMPT  USER  FOR  RUN  DATE 

C 

PRINT  X,'  ENTER  DATE  (EG, 19/ 12/83) ' 

PRINT  X 
READ  50, DATE 
50  FORMAT <A8) 

C 

C  PROMPT  USER  FOR  PRIMARY  AND  TIE-BREAKER 

C  PRIORITIES  FOR  THE  CREW  FILE 

C 

PRINT  X,'  ENTER  PRIORITY  FOR  CREW  FILE  (EG,  LVF(5>)' 

PRINT  X 

READ  100 ,PRI01 

PRINT  X,'  ENTER  TIE-BREAKER  PRIORITY' 

PRINT  X 

READ  100,PRIO2 
100  FORMAT (A4) 

C 

C  PROMPT  USER  FOR  NUMBER  OF  DAYS  IN  THE  MONTH 
C 


PRINT  X,'  ENTER  NUMBER  OF  DAYS  IN  MONTH' 
PRINT  X 
READ  X, NODAYS 
C 

C  PREPARE  FILE  'SLAMIN'  FOR  THE  NEW  DATA 
C 

OPEN<  10,FILE='SU*1IN') 

REWIND  18 


C 

C 

C 

C 


C 

C 

C 

C 

C 

C 

C 


1 


WRITE  SUM  CONTROL  CARDS  TO  FILE  'SLAMIN' 
USING  INFORMATION  PROVIDED  FROM  ABOVE  PROMPTS 


WR ITE ( 1 0 , X) ' GEN , RNUSS , CREW  SCHEDULE , ' , DATE , ' , 1 ; ' 
WRITE< 18, X) 'LIMITS, 20, 12, 180}' 

WRITE( 10 ,X) 'PRIORITY/ 16, ' ,PRI01,' ,/NCLNR,' ,PRI02,' ;' 
WRITE( 10, X) 'NETWORK;' 

CONSTRUCT  SLAMIN  NETWORK  OF  15  QUEUE  NODES 
REPRESENTING  THE  15  LAUNCH  CONTROL  CENTERS. 

LABELS  FOR  EACH  QUEUE  NODE  PROVIDED  BY 
CHARACTER  ARRAY  'QUEUE'.  FOR  MORE  INFOR¬ 
MATION,  SEE  USER  GUIDE  AND  SUM  NETWORK  DIAGRAM 


DO  1  1-1,15 

WRITE< 18 .X) QUEUE( I) . '  QUEUE('.I 


WRITE< 18, X)' 
WRITE( 10 ,X) ' 
WRITE< 10, X)  ' 
CONTINUE 
WRITE(  10  ,X) ' 
WRITE < 10 ,X) ' INIT 
WRITE< 10, X) 'FIN; 


ACTIVITYC  1>/'  , 
EVENT,', I,';' 
TERMINATE;' 

ENDNETWORK;' 
0.0,', REAL (NODAYS) 
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c 

c 

c 
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c 

c 


SLAM  NETWORK  AND  ASSOCIATED  CONTROL  CARDS 
COMPLETE.  INITIALIZE  CREW  ATTRIBUTES  FOR 
NUMBER  OF  ALERTS  AND  SPARE  ATTRIBUTE  TO  8 


ALERTS-0 .0 
SPARE-0.0 


PROMPT  USER  FOR  TOTAL  NUMBER  OF  CREWS  AND 
VERIFY  NUMBER  OF  CREWS  108  OR  LESS,  IF  NOT, 
PRINT  WARNING  AND  REQUEST  NEW  INPUT 


PRINT  X,'  ENTER  NUMBER  OF  CREWS' 

PRINT  X 

READ  X ,NOCRWS 

IF  (NOCRWS.GT. 100)  THEN 

PRINT  X,'  WARNING:  NUMBER  OF  CREWS  MUST  BE  188  OR  LESS' 
GO  TO  11 
ENDIF 

WRITE ( 10 ,X)NOCRWS 


INFORM  USER  T**T  FIRST  FIFTEEN  ENTRIES 


A-32 


V  p* 


C  REPRESENT  THE  ALERTS  FOR  DAY  1 
C 

PRINT  X,'  FIRST  FIFTEEN  ENTRIES  SENT  ON  ALERT  FOR  DAY  1' 

C 

C  BEGIN  LOOP  TO  GATHER  ATTRIBUTES  FOR  EACH  CREW. 

C  REINITIALIZE  LEAVE  DATES  TO  0  BEFORE  NEXT 

C  CREW  ENTRY 

C 

DO  5  1=1 ,NOCRWS 
DO  10  J=1 ,3 

STRTLV< J)=0 .0 
ENDLVK  J)=0 .0 
18  CONTINUE 

PRINT  X,'  ENTRY  NUMBER  ',1 
PRINT  X 
C 

C  PROMPT  USER  FOR  IDENTIFYING  DATA  ON  EACH  CREW. 

C  CHECK  FOR  IMPROPER  DATA,  PRINT  WARNING(S) 

C  AND  REQUEST  NEW  INPUT 
C 

PRINT  X,'  ENTER  CREW  NUMBER,  FLIGHT,  SCP  QUAL,  AND  TYPE 
PRINT  X 

READ  X , CRWNUM , FLTDES , SCPDES , CRWTYP 
22  IF  < CRWNUM. LE. 0.0. OR. CRWUM. GT.  100.) THEN 

PRINT  X,'  WAGING:  CREW  NUMBER  OUT  OF  RANGE' 

PRINT  X,'  ENTER  CREW  NUMBER  < 1-100)' 

PRINT  X 
READ  X, CRWNUM 
GO  TO  22 
ENDIF 

33  IF  (FLTDES. LE. 0.0. OR. FLTDES. GT. 17.)  THEN 

PRINT  X,'  WARNING:  FLIGHT  DESIGNATOR  OUT  FRNGE' 

PRINT  X,'  ENTER  FLIGHT  DESIGNATOR  (1-17)' 

PRINT  X 
READ  X, FLTDES 
GO  TO  33 
ENDIF 

44  IF  (SCPDES. LT. 0.0. OR. SCPDES. GT.l.)  THEN 

PRINT  X,'  WARNING:  SCP  QUALIFICATION  OUT  OF  RANGE' 

PRINT  X,'  ENTER  SCP  QUALIFICATION  (0  OR  1) ' 

PRINT  X 
READ  X, SCPDES 
GO  TO  44 
ENDIF 

55  IF  (CRWTYP. LT. 0.0. OR. CRWTYP. GT. 2.)  THEN 

PRINT  X,'  WARNING:  CREW  TYPE  OUT  OF  RANGE' 

PRINT  X,'  ENTER  CREW  TYPE  (0,1,2)' 


PRINT  X,7  HOW  MANY  LEAVE  PERIODS  REQUESTED  (0-3) 7 
PRINT  X 
READ  X ,LVREQ 
DO  IS  J*1,LVREQ 

PRINT  X,7  ENTER  START  AND  END  LEAVE  DATES,  PERIOD  7 ,J 
PRINT  X 

READ  X , STRTLV ( J) , ENDLV  <  J) 

IF  (ENDLV(J) .LT. STRTLV (J))  THEN 

PRINT  X,7  WARNINGS  END  LEAVE  LESS  THAN  START  LEAVE  DATE7 
GO  TO  66 
ENDIF 

CONTINUE 

PROMPT  USER  FOR  ACTUAL  NUMBER  OF  LEAVE  DAYS 
AS  OPPOSED  TO  OTHER  TYPES  OF  NONAVAILABILITY 

IF  (LVREQ.NE.0)  THEN 

PRINT  X, 'ENTER  NUMBER  OF  ACTUAL  LEAVE  DAYS  FOR  CREW  7,CRWNUM 
PRINT  X 
READ  X , LVDAYS 
ELSE 

LVDAYS=0 

ENDIF 

WRITE  INDIVIDUAL  CREW  DATA  TO  INPUT  FILE  'SLAMIN7 

WRITE ( 1 0 , X) CRWNUM , FLTDES , SCPDES , CRWTYP , ALERTS , SPARE , STRTLV  < 1) ,E 
1NDLVC 1) , STRTLV (2) ,ENDLV<2> ,STRTLV(3> ,ENDLV<3> 

WRITE< 10, X) LVDAYS 
CONTINUE 

BEGIN  TRAINING  DATA  COLLECTION 

PROMPT  USER  FOR  NUMBER  OF  TYPES  OF  CLASSROOM 

TRAINING  TO  BE  SCHEDULED 

PRINT  X 

PRINT  X,7  ENTER  THE  NUMBER  OF  CLASSROOM-TYPE  TRAINING  (1,2,3) 7 
PRINT  X 
READ  X ,NUMTRN 
WRITE( 10,X)NUMTRN 
DO  20  I-1,NUMTRN 
ITYPE(I)*I 

PROMPT  USER  FOR  NUMERIC  CODE  FOR  EACH 
TRAINING  TYPE 

PRINT  X,7  ENTER  TRAINING  CODE  FOR  TYPE  7,ITYPE(I) 

PRINT  X 

READ  X ,MRKDAY( I) 

PROMPT  USER  FOR  mx  fiMD  MIN  CLASS  SIZES 
CHECK  INPUT  FOR  CONSISTENCY 


PRINT  X,'  ENTER  httXIMUM  AND  MINIMUM  CLASS  SIZE" 

PRINT  * 

READ  X,MAXCLS(I) ,MINCLS(I) 

IF  (MINCLS(I) .GT.MAXCLSC I) )  THEN 

PRINT  X,'  kWRNINGs  MINIMUM  CLASS  LARGER  THEN  MAXIMIM  CLASS' 
GO  TO  77 
ENDIF  ' 

PROMPT  USER  FOR  POSSIBLE  DATES  TO  SCHEDULE 
CLASS  FOR  EACH  TYPE  TRAINING.  FIFTEEN 
POSSIBILITIES  ARE  ALLOWED 

DO  25  J=l,15 

PRINT  X ENTER  TRAINING  DAY  FOR  TYPE  ',ITYPE(I> 

PRINT  X 

READ  X,ITRNDY<I ,J> 

WRITE<  18 ,30  ITRNDYC I ,  J> 

CONTINUE 

WRITE(  10  ,X>MRKDAY<  I) 

WRITE (  10 ,X)MAXCLS(  I)  ,MINCLS(I) 

CONTINUE 

PROMPT  USER  FOR  THE  NUMBER  OF  MPT  PERIODS 
TO  BE  SCHEDULED  FOR  EACH  CREW.  IF  MORE 
TH^N  1  PERIOD  REQUESTED,  PROMPT  USER  FOR 
MINIMUM  TIME  ALLOWED  BETWEEN  MPT  PERIODS 

PRINT  X 

PRINT  X,'  ENTER  NUMBER  OF  MPT  PERIODS  PER  CREW  (1  OR  2)' 

PRINT  * 

READ  X ,NUMMPT 
WRITE<10,X)NUMMPT 
IF  (NUMMPT.GT.  1)  THEN 

PRINT  X,'  ENTER  MINIMUM  TIME  BEWTEEN  MPT  PERIODS' 

PRINT  X 
READ  X.MTBMPT 
WRITE<10,X)MTBMPT 
ENDIF 

PROMPT  USER  FOR  NUMBER  OF  MPT  PERIODS  AVAILABLE 
ON  EACH  DAY  OF  THE  MONTH 

PRINT  X,'  ENTER  NUMBER  OF  MPT  PERIDS  PER  DAY' 

PRINT  X 

WRITE< 10, X) NODAYS 
DO  30  I*! ,NGOAYS 
PRINT  X,'  DAY  ',1 
PRINT  X 

READ  X  ,MPTDAYU) 

WRITE< 10,X)MPTDAY< I) 

CONTINUE 

PROMPT  USER  FOR  NWIMUM  ALLOWABLE  ALERTS 
FOR  EACH  CREW  TYPE 


PRINT  X,'  ENTER  httXIMUM  NUMBER  OF  ALERTS  FOR:' 

PRINT  X,'  LINE  CREWS,  FLT  COMhttNDERS,  AND  DOV/DOT' 

PRINT  X 

READ  X ,MAXLIN,MAXFCC,MAXSHP 
WRITE< 18 ,X) MAXLIN ,MAXFCC ,MAXSHP 
C 

C  PROMPT  USER  FOR  ALERT  ASSIGNMENT  PERCENTAGES 
C  (REFERENCE  TO  USER  WWUAL  REQUIRED  TO 
C  UNDERST AND  SIGNIFICANCE  OF  THESE  SETTINGS) 

C  CHECK  PERCENTAGES  FOR  CONSISTENCY 
C 

PRINT  X,'  ENTER  PERCENTAGES  FOR  ALERT  ASSIGNMENTS: ' 

88  PRINT  X,'  FOR  NON-SCP  ALERTS  —  DOV/DOT,  FLT  CC,  INTEGRAL' 
PRINT  X 

READ  X , SHPPCT , FCCPCT , FLTPCT 

IF  (FLTPCT. LT.FCCPCT.OR.FCCPCT.LT. SHPPCT)  THEN 

PRINT  X,'  WARNING:  INCONSISTENT  DATA,  REINPUT  ALERT  V.' 
GO  TO  88 
ENDIF 

99  PRINT  X,'  FOR  SCP  ALERTS  --  DOV/DOT,  INTEGRAL' 

PRINT  X 

READ  X ,SHPCTS,FTPCTS 

IF  ( FTPCTS . LT . SHPCTS)  THEN 

PRINT  X,'  WARNING:  INCONSISTENT  DATA,  RE  INPUT  ALERT  V.' 
GO  TO  99 
ENDIF 

WRITE( 10 , X)  SHPPCT , FCCPCT , FLTPCT , SHPCTS , FTPCTS 
C 

C  PROMPT  USER  FOR  DESIRED  RANDOM  NUMBER  STREAMS 
C 

PRINT  X, 'ENTER  THE  2  RANDOM  NUMBER  STREAMS  (1-18)' 

PRINT  X 

READ  X , I STRM 1 , I STRM2 
WRITE( 10 ,X) I STRM 1 , ISTRM2 
C 

C  CLOSE  DATA  FILE  'SLAMIN' .  CREW  DATA  ENTRY  COMPLETE 
C 

CLOSE ( 10) 

END 


LIST  OF  VARIABLES:  SLMWRT 

ARRAYSl 

ENDLV(3>  -  crew  requested  end  leave  dates  (attributes  8,  10,  12); 

ITRNDY(3,15>  -  available  training  days  -for  each  type  of  classroom 
training:  integer 


ITYPE<3>  -  identifies  type  of  classroom  training;  integer 

MAXCLS<3)  -  maximum  class  size  for  each  type  classroom  training;  integer 

MINCLS(3)  -  minimum  class  size  for  each  type  classroom  training;  integer 

MPTDAY<31)  -  number  of  available  MPT  sessions  per  day;  integer 

MRKDAYC3)  -  numeric  code  of  each  type  classroom  training;  integer 

QUEUE(IS)  -  labels  for  SLAM  network  queues;  character 

STRTLAK3)  -  crew  requested  end  leave  dates  (attributes  7,  9,  il);  real 

VARIABLES: 

ALERTS  -  represents  attribute  5,  number  of  alerts,  for  individual  crew 
information;  real 

CRMNUM  -  represents  attribute  1,  crew  number,  for  individual  crew 
information;  real 

CRWTYP  -  represents  attribute  4,  crew  type,  for  individual  crew 
information;  real 

DATE  -  date  of  run  on  SLAM  control  card;  character 

FCCPCT  -  percentage  of  flight  commanders  sent  to  non-SCP  alerts;  real 

FLTDES  -  represents  attribute  2,  flight  designator,  for  individual  crew 
information;  real 

FLTPCT  -  percentage  of  crews  sent  to  their  assigned  flight  for  non-SCP 
alerts;  real 

FTPCTS  -  percentage  of  crews  sent  to  their  assigned  flight  for  SCP 
alerts;  real 

ISTRM1  -  random  number  stream  used  for  non-SCP  alerts;  integer 
ISTRM2  -  random  number  stream  used  for  SCP  alerts;  integer 
LVDAYS  -  number  of  actual  leave  days  for  each  crew;  integer 
LVREQ  -  number  of  leave  periods  requested  by  crew;  integer 
MAXFCC  -  maximum  number  of  alerts  for  flight  commander;  integer 

MAXLIN  -  maximum  number  of  alerts  for  line  crews;  integer 

MAXSHP  -  maximum  number  of  alerts  for  DOV/DOT  crews;  integer 


MT8MPT  -  minimum  time  between  MPT  training;  integer 

NOCRWS  -  total  number  of  crews;  integer 

NODAYS  -  number  of  days  in  month;  integer 

NUMMPT  -  number  of  MPT  sessions  requested  per  crew;  integer 

NUMTRN  -  number  of  classroom  type  training;  integer 

PRI01  -  primary  priority  for  EA  queue;  character 

PRI02  -  tie-breaker  priority  for  EA  queue;  character 

SCPDES  -  represents  attribute  3,  scp  qualification,  for  individual  crew 
information;  real 

SHPCTS  -  percentage  of  DOW/DOT  crews  sent  to  SCP  alerts;  real 

SHPPCT  -  percentage  of  DOV/DOT  crews  sent  to  non-SCP  alerts;  real 

SPARE  -  represents  spare  attribute  6  for  individual  crew  information; 
real 


PROGRAM  LISTING;  SLAM  CONTROL  CARDS 


BRAV 


GEN , RNUSS , CREW  SCHEDULE , 8 1/27/84 , 1 ; 
LIMITS, 20 , 12, 100 ; 

PRIORITY/16, LVF<5) ,/NCLNR,LVF?4> ; 
NETWORK; 

ALFA  QUEUE ( 1)  ; 

ACTIVITY? 1>/1,1.0; 

EVENT, 1 ; 

TERMINATE; 

QUEUE (2)  ; 

ACTIVITY?  l)/2, 1 .0 ; 

EVENT, 2; 

TERMINATE; 

QUEUE (3) ; 

ACTIVITY< l)/3, 1 .0; 

EVENT, 3; 

TERMINATE; 

QUEUE (4) ; 

ACTIVITY? l)/4, 1 .0 ; 

EVENT, 4; 

TERMINATE; 

QUEUE? 5) ; 

ACTIVITY? l)/5, 1.0; 

EVENT, 5; 

TERMINATE; 


CHAR 


DELT 


ECHO 
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FOXT  QUEUE (6) ; 

ACTIVITY! l)/6, 1.0; 
EVENT, 6; 

TERMINATE; 

GOLF  QUEUE! 7) ; 

ACTIVITY< l)/7, 1 .8; 
EVENT,?; 

TERMINATE; 

HOTE  QUEUE (8) ; 

ACTIVITY! l)/8, 1 .0 ; 
EVENT, 8; 

TERMINATE; 

I NO I  QUEUE (9) ; 

ACTIVITY! l)/9, 1.0; 
EVENT, 9; 

TERMINATE; 

JULI  QUEUE! 18) ; 

ACTIVITY! 1)/ 10, 1.0; 
EVENT, 10; 

TERMINATE; 

KILO  QUEUE!  11); 

ACTIVITY! 1)/1 1,1.0; 
EVENT, 11; 

TERMINATE; 

LIMA  QUEUE! 12) ; 

ACTIVITY! 1)/ 12, 1.0; 
EVENT, 12; 

TERMINATE; 

MIKE  QUEUE! 13); 

ACTIVITY! 1)/13, 1.0; 
EVENT, 13; 

TERMINATE; 

NOVE  QUEUE! 14) ; 

ACTIVITY! 1)/ 14, 1.0; 
EVENT, 14; 

TERMINATE; 

OSCA  QUEUE! 15) ; 

ACTIVITY! 1>/15, 1.0; 
EVENT, 15; 

TERMINATE; 

ENDNETWORK; 

INIT ,0.0,30 . ; 


ooooooooo 


PROGRAM  LISTING;  SLAM  CREW  SCHEDULING  PROGRAM 


PROGRAM  MAIN< INPUT , OUTPUT , TAPE5= INPUT ,TAPE6=0UTPUT , TAPE? , TAPE  15) 

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 
X  PROGRAM  'tolN'  IS  USED  TO  DIMENSION  X 
X  SLAM  STORAGE  ARRAYS,  SPECIFY  INPUT  X 
X  AND  OUTPUT  PARAMETERS  AND  CALL  THE  X 
X  SLAM  SUBROUTINE  WHICH  SUPPLIES  EXEC-  X 
X  UTIVE  CONTROL  FOR  THE  SIMULATION  X 
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 

DIMENSION  NSET<5800) 

COMMON/SCQM 1/ATRI B< 100) ,DD<100> ,DDL<  108) , DTNQW , 1 1 ,MFA ,MSTOP ,NCLNR 
1 ,NCRDR,NPRNT,NNRUN,NNSET,NTAPE,SS(  100) ,SSL( 100) ,TNEXT,TNOW,XX( 100) 
COMMON  QSETC5000) 

EQU I VALENCE <NSET  < 1) ,QSET< 1) ) 

NNSET»5080 
NCRDR=5 
NPRNT=6 
NTAPE=7 
CALL  SLAM 
STOP 
END 
C 

C  XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 

C  X  SUBROUTINE  'INTLC'  IS  USED  TO  INI-  X 

C  X  TIALIZE  PROGRAM  VARIABLES  AND  READ  X 

C  X  CREW  AND  TRAINING  INFORMATION  FROM  X 

C  X  THE  DATA  FILE  'SLAMIN'  X 

C  XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 

c 

SUBROUTINE  INTLC 

COMMON/SCOM 1/ATRI B< 180) ,DD<100> ,DDL(100> , DTNOW , 1 1 ,MFA ,MSTQP ,NCLNR 
1 ,NCRDR,NPRNT,NNRUN,NNSET,NTAPE,SS(  100) ,SSL(108) ,TNEXT ,TNOW,XX( 100) 
COMMON/UCOMl/IDAY,NXTDAY ,  IFILE ,  ISCHED<  100,32)  ,DUmY<  14)  ,LVBEG<3)  ,L 
1VEND(3) , INTFLT  < 100) ,NOCRWS , NODAYS ,NUMTRN ,MAXLIN ,MAXFCC ,MAXSHP 
C0MM0N/UC0M2/ 1 TRNDY  <  3 , 15) ,ITYPE<3) ,MRKDA<) ,MPTDAY(31) ,NUMMPT,MTB 
1MPT ,N,MAXCLS(3) ,MINCLS<3) 

C0MMCN/UC0M3/N0ALTS  < 188) ,FREDAY< 180) , INTALT  < 100) ,LVDAYS< 180) 
C0MMQN/UC0M5/SHPPCT , FCCPCT , FLTPCT , SHPCTS , FTPCTS , I STRM 1 , I STRM2 
DATA  ITRNDY/45X0/ 

DATA  DUMMY/ 14X0.8/ 

DATA  LVBEG/3X0/ 

DATA  LVEND/3X8/ 

DATA  MPTDAY/31X6/ 

DATA  INTFLT/ 108X0/ 

DO  1  1=1,108 
DO  2  J= 1 , 32 
ISCHED< I , J)=0 
2  CONTINUE 

1  CONTINUE 
IFILE=0 
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IDAY=8 

NXTDAY=0 

READ ( NCRDR , X  >  NOCRWS 

CREW  ATTRIBUTES  AND  LEAVE  DAYS  ARE  READ  IN 
FOR  EACH  CREW.  FROM  THIS  DATA  THE  ARRAY 
' INTFLT"  IS  CREATED  AND  CONTAINS  THE 
ASSIGNED  FLIGHT  FOR  EACH  CREW  WITH  FLIGHT 
COMMANDERS  IDENTIFIED  BY  A  NEGATIVE  NUMBER. 

THIS  ARRAY  WILL  BE  USED  TO  EASE  DATA  COLLECTION 
IN  SUBROUTINE  "STATS' 

NOTE  THAT  THE  FIRST  15  ENTRIES  ARE  SENT  TO 
THE  ALERT  QUEUES  TO  SIMULATE  THE  FIRST  DAY 
OF  THE  ALERT  SCHEDULE.  FOLLOWING  THESE 
FIRST  15  ENTRIES,  THE  REMAINDER  OF  THE  CREWS 
ARE  SENT  TO  THE  EA  QUEUE  <FILE  16) 

OR  IF  LEAVE  IS  SCHEDULED  TO  BEGIN  ON  THE 
FIRST  DAY,  PLACED  ON  THE  EVENT  CALENDAR 
TO  RETURN  AT  COMPLETION  OF  THE  LEAVE 

DO  5  1=1,15 

READ (NCRDR, 30  (ATRIB(J) ,J=1,12> 

READ<NCRDR,30 LVDAYS(NINT  <ATRIB( 1) ) ) 

IF  (NINT (ATRIB<4) ) .EQ. 1)  THEN 

INTFLT<NINT<ATRIB< 1) ) )=-<NINT<ATRIB<2) ) ) 
ELSE 

INTFLT<NINT<ATRIB< 1) ) )=NINT<ATRIB<2) ) 
ENDIF 

CALL  FILEM< I ,ATRIB) 

CONTINUE 

DO  10  1=16, NOCRWS 

READ(NCRDR,30  <ATRIB<J) ,J=1,12) 

READ  <  NCRDR ,  30  LVDAYS  <  N I NT  <  ATR I B  < 1 ) ) ) 

IF  <NINT<ATRI8<4>) .EQ.l)  THEN 

INTFLT<NINT<ATRIB< 1) ) )=-<NINT(ATRIB<2) ) ) 
ELSE 

INTFLT<NINT<ATRIB< 1) ) )=NINT<ATRIB<2) ) 
ENDIF 

IF  <NINT<ATRIB< 7)) .EQ.l)  THEN 

DO  12  J=NINT<ATRIB<7)) ,NINT<ATRIB<8) ) 
ISCHED<NINT<ATRIB< 1)> ,J)=77 
CONTINUE 

DURLV=ATR I B  <  8) -ATR I B  <  7)  + 1 . 2 
CALL  SCHDL ( 25 , DURLV , ATR I B) 

GO  TO  10 
ENDIF 

CALL  FILEM< 16,ATRIB) 

CONTINUE 

TRAINING  INFORMATION  FOR  BOTH  CLASSROOM 
*WD  MPT  PERIODS  IS  READ  FROM  THE  INPUT  FILE 


READ (NCRDR,  30  NUMTRN 


DO  15  I=1,NUMTRN 
DO  20  J=1 , 15 
READ(NCRDR,X)  ITRNDYC I ,  J) 

CONTINUE 

READ (NCRDR , X) MRKDAY ( I ) 

READ  <  NCRDR , X ) MAXCLS  < I ) ,MINCLS(I> 

I TYPE ( I) =1 
CONTINUE 

READ  C  NCRDR,  X)NUMMPT 
IF  (NUMMPT.GT. 1)  THEN 
READ (NCRDR , X)  MTBMPT 
ELSE 

MTBMPT=0 

ENDIF 

READ < NCRDR, X) NODAYS 
DO  25  1=1, NODAYS 

READ (NCRDR , X) MPTDAY ( I ) 

CONTINUE 

READ  MAXIMUM  NUMBER  OF  ALERTS  FOR  EACH  CREW 
CATEGORY,  INTERNAL  ALERT  PERCENTAGES  AND 
SU*I  RANDOM  NUMBER  STREAMS  TO  BE  USED 

READ (NCRDR ,  30  MAXLIN,MAXFCC ,MAXSHP 

READ(NCRDR ,30  SHPPCT , FCCPCT ,FLTPCT , SHPCTS , FTPCTS 

READ(NCRDR,30  I STRM 1 , 1 STRM2 

THIS  CALL  TO  THE  $U*\  SUBROUTINE  'SCHDL' 

IS  USED  TO  PLACE  THE  TIME  TO  START  THE  FIRST 
LEAVE  SEARCH  ON  THE  EVENT  CALENDAR. 

ARRAY  'DUMMY'  IS  USED  SINCE  THIS  EVENT 
DOES  NOT  CONCERN  A  SPECIFIC  CREW 

CALL  SCHDL (30, 0.8, DUMMY) 

RETURN 

END 

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 
X  SUBROUTINE  'EVENT'  IS  USED  TO  DIRECT  X 
X  PROGRAM  ACTIONS  DURING  THE  ALERT  X 
X  SCHEDULING  PHASE  OF  THE  SIMULATION.  X 
X  TRANSACTIONS  ARRIVING  AT  THIS  SUB-  X 
X  ROUTINE  CARRY  A  CODE  (IFN)  WHICH  X 
X  DETERMINES  THEIR  DISPOSITION  X 

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 

SUBROUTINE  EVENT (IFN) 

C0MMQN/SCQM1/ATRIB( 100) ,DD(  100)  ,DDL(100) ,DTNOW,I I ,MFA,MSTOP,NCLNR 
1, NCRDR ,NPRNT,NNRUN,M'ISET,NTAPE,SS<  100)  ,SSL(  100)  ,TNEXT,TNOW,XX<  100) 
COMMON/ 3COM  1/IDAY ,NXTDAY , I  FILE , ISCHED( 100 ,32) ,DUMMY(14) ,LVBEG(3)  ,L 
1VEND( 3) , INTFLT ( 100) ,NOCRWS , NODAYS ,NUMTRN ,MAXLIN ,MAXFCC ,MAXSHP 
C0MM0N/UC0M5/SHPPCT , FCCPCT , FLTPCT , SHPCTS , FTPCTS , I STRM 1 , I STRM2 
IFILE=IFN 
I DAY=N I NT ( TNOW) 


ooo  ooooon  oooooon  oooooooo  oooo  nooon 


NXTDAY=IDAY+ 1 


IFN  OF  25  INDICATES  A  CREW  IS  RETURNING 
FROM  CREW  REST  OR  LEAVE.  CREW  IS  NOW  SENT 
TO  THE  EA  QUEUE 

IF  < IFN.EQ.25)  THEN 
CALL  FILEMC 16,ATRIB) 

RETURN 

IFN  OF  30  INDICATES  TIME  TO  SEARCH  CREW  FOR 
LEAVE  REQUESTS 

ELSE  IF  (IFN.EQ.30)  THEN 
CALL  LEAVE 
RETURN 
ENDIF 

ATRIB<1)  SET  TO  ZERO  INDICATES  DUMMY  CREW 
THE  DUMMY  CREW  TRANSACTION  IS  USED  WHEN  NO 
CREWS  WERE  AVAILABLE  THE  PREVIOUS  DAY  FOR 
THAT  LCC.  THIS  TRANSACTION  IS  THEN  SENT  TO 
STATEMENT  50  FOR  TRANSFER  TO  THE  CORRECT 
NEXT  ALERT  ROUTINE 

IF  <NINT<ATRIB< 1)> .EQ.0)  GO  TO  50 

UPDATE  THE  CREW  SCHEDULE,  ARRAY  'ISCHED', 

WITH  THE  COMPLETED  ALERT.  CODE  99  IS  USED 
TO  INDICATE  THE  DAY  OF  RETURN  FROM  ALERT. 

ALSO,  THE  NUMBER  OF  ALERTS  <ATRIB<5>)  IS 
INCREASED  BY  1 

ISCHED<NINT<ATRIB< 1>> ,IDAY)=IFILE 
ISCHED<NINT<ATRIB<  I) ) , < IDAY+ 1) ) =99 
ATRIB<5)=ATRIB<5>  +  1.0 

CHECK  CREW  COMPLETING  ALERT  FOR  MAXIMUM  NUMBER 
OF  ALERTS.  IF  MAXIMUM  REACHED  CHECK  CREW  FOR 
LEAVE  REQUESTS  FOR  THE  REMAINDER  OF  THE  MONTH 
AND  FILE  CREW  IN  APPLICABLE  MAX  ALERT  FILE 

IF  <NINT<ATRIB<4))  .EQ.0  .<WD.  NINT<ATRIB<5) )  .GE.MAXLIN)  THEN 
CALL  LVUPDT 
CALL  FILEM< 17,ATRIB) 

ELSE  IF  <NINT<ATRIB< 4) ) .EQ.  I  .AND.  NINT<ATRIB<5> > .GE.MAXFCC)  THEN 
CALL  LVUPDT 
CALL  FILEM< 19,ATRIB) 

ELSE  IF  <NINT<ATRIB<4) > .EQ.2  .AND.  NINT<ATRIB<5> > .GE.MAXSHP)  THEN 
CALL  LVUPDT 
CALL  FILEM<  18,ATRIB> 

CHECK  OTHER  RETURNING  CREWS  FOR  LEAVE  IMMEDIATELY 
FOLLOWING  RETURN  FROM  ALERT.  IF  FOUND,  UPDATE 
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CREW  SCHEDULE  AND  PLACE  ON  EVENT  CALENDAR  FOR 
LEAVE  RETURN 

ELSE  IF  <NINT<ATRIB<7>> .EQ. <NXTDAY+ 1) )  THEN 
DO  75  J=NINT<ATRIB<7)> ,NINT<ATRIB<8>) 
ISCHED<NINT<ATRIB< 1) ) ,J)=77 
CONTINUE 

DURLV=ATR I B<  8) -ATR I B  <  7) +  2 . 2 
CALL  SCHDL  <  25 , DURLV ,  ATR  I B) 

ELSE  IF  <NINT<ATRIB<9) ) .EQ. <NXTDAY+ 1) )  THEN 
DO  76  J=NINT<ATRIB<9) ) ,NINT<ATRIB< 10)) 
ISCHED<NINT<ATRIB< 1) > ,  J)=7 6 
CONTINUE 

DURLV=ATRIB< 10) -ATRIB<9) +2.2 
CALL  SCHDL<25, DURLV, ATRIB) 

ELSE  IF  <NINT<ATRIB< 1 1) ) .EQ.NTDY+l))  THEN 
DO  77  J=NINT <ATRIB<  ID)  ,NINT <ATRIB<  12) ) 
ISCHED<NINT<ATRIB<  D)  ,J)=76 
CONTINUE 

DURLV=ATRIB< 12) -ATRIB< 1 1) +2.2 
CALL  SCHDL <25, DURLV, ATR IB) 

FOR  ALL  OTHER  CREWS  COMPLETING  ALERT,  PLACE 
CREW  ON  EVENT  CALENDAR  TO  RETURN  TO  THE 
EA  QUEUE  FOLLOWING  CREW  REST  PERIOD 

ELSE 

CALL  SCHDL <25, 1.5, ATRIB) 

ENDIF 

BASED  ON  LOCATION  OF  JUST  COMPLETED  ALERT, 

CALL  NEXT  ALERT  SUBROUTINE  TO  SCHEDULE  THE 
NEXT  DAY  ALERT  CREW 

GO  TO< 1,2, 3, 4, 5, 6, 7, 8, 9 ,10, 11, 12, 13, 14 ,15) ,IFN 

CALL  NXTSCP 

RETURN 

CALL  NXTALT 

RETURN 

CALL  NXTALT 

RETURN 

CALL  NXTALT 

RETURN 

CALL  NXTALT 

RETURN 

CALL  NXTSCP 

RETURN 

CALL  NXTALT 

RETURN 

CALL  NXTALT 

RETURN 

CALL  NXTALT 

RETURN 

CALL  NXTALT 


RETURN 
CALL  NXTSCP 
RETURN 
CALL  NXTALT 
RETURN 
CALL  NXTALT 
RETURN 
CALL  NXTALT 
RETURN 
CALL  NXTALT 
RETURN 
END 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

X  SUBROUTINE  'NXTALT'  IS  USED  TO  X 

X  SCHEDULE  THE  ALERT  CREWS  FOR  ALL  X 
X'  NON-SCP  LAUNCH  CONTROL  CENTERS  X 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

SUBROUTINE  NXTALT 

COMMON/SCOM 1/ATRI8< 189) ,D18> ,DDL(  188) , DTNOW , 1 1 ,MFA ,MSTOP ,NCLNR 
1  ,NCRDR ,NPRNT ,hMRUN ,NNSET ,NTAPE , SS ( 100) ,SSL( 100) ,TNEXT,TNOW,XX< 100) 
COMMON/UCOM1/IDAY ,NXTDAY , IFILE, ISCHED< 100,32) ,DUMMY<14) ,LVBEG<3> ,L 
1VEND<3) ,INTFLT( 108) ,NOCRWS, NODAYS ,NUMTRN,MAXLIN,MAXFCC,MAXSHP 
C0MM0N/UC0M5/SHPPCT , FCCPCT , FLTPCT , SHPCTS , FTPCTS , I STRM 1 , I STRM2 

THIS  SETS  THE  VARIABLE  'NEXT'  EQUAL  TO  THE 
FIRST  CREW  IN  THE  EA  QUEUE.  IF  'NEXT' 

EQUALS  9,  THEN  THE  CREW  FILE  IS  EMPTY.  IN 
THIS  CASE  A  WARNING  MESSAGE  IS  PRINTED  FOR 
THE  DAY  WD  APPLICABLE  LCC.  A  DUWY 
TRANSACTION  IS  THEN  USED  TO  INSURE  A  RETURN 
TO  THIS  SUBROUTINE  FOR  THE  FOLLOWING  DAYS 
ALERT  SCHEDULING 

NEXT=MMFE( 16) 

IF  (NEXT.EQ.0)  THEN 

WRITE<6,X)'  CREW  FILE  EMPTY  ON  DAY  ' ,NXTDAY, '  FOR  LCC  ', IFILE 
CALL  SCHDL< IFILE, 1.0, DUMMY) 

RETURN 

ENDIF 

THE  EA  QUEUE  IS  SEARCHED  FOR  A  SPECIFIC  CREW 
BASED  ON  THE  RANDOM  NUMBER  DRAWN  AND  THE 
SPECIFIED  PERCENTAGES 

RN=DRAND<ISTRM1) 

CALL  C0PY<-NEXT,16,ATRIB) 

IF  (RN.LE.SHPPCT)  THEN 

IF  <NINT<ATRIB<4) ) .EQ.2)  THEN 
CALL  RM0VE(-NEXT,16,ATRIB) 

CALL  FILEMC IFILE, ATRIB) 

RETURN 

ENDIF 


ELSE  IF  (RN.LE.FCCPCT)  THEN 

IF  <NINT(ATRIB<4>) .EQ.l  .AND.  NINT<ATRIB(2> ) .EQ.IFILE)  THEN 
CALL  RMGVEC-NEXT, 16,ATRIB) 

CALL  FILEM< IFILE,ATRIB> 

RETURN 

ENDIF 

ELSE  IF  (RN.LE.FLTPCT)  THEN 

IF  <NINT(ATRIB(2)> .EQ.IFILE)  THEN 
CALL  RMGUE(-NEXT,16,ATRIB) 

CALL  FILEM( IFILE,ATRIB) 

RETURN 

ENDIF 

ELSE 

IF  <NINT(ATRIB<4) ) .EQ.0)  THEN 
CALL  RMOVE(-NEXT, 16,ATRIB) 

CALL  FILEM< IFILE,ATRIB) 

RETURN 

ENDIF 

ENDIF 

NEXT=NSUCR(NEXT) 

IF  (NEXT.NE.0)  GO  TO  10 

IF  A  CREW  WITH  THE  REQUESTED  ATTRIBUTES  IS 
NOT  FOUND,  THEN  SEARCH  FILE  FOR  LINE  CREW 

NEXT=MNFE( 16) 

CALL  C0PY(-NEXT,16,ATRIB) 

IF  (NINT(ATRIB(4)) .EQ.0)  THEN 
CALL  RMOVE(-NEXT, 16,ATRIB) 

CALL  FILEM(IFILE,ATRIB) 

RETURN 

ENDIF 

NEXT =NSUCR  (  NEXT) 

IF  (NEXT.NE.0)  GO  TO  20 

IF  LINE  CREW  NOT  AVAILABLE,  SELECT  FIRST 
CREW  IN  FILE 

CALL  RMOVE(-MMFE( 16) , 16,ATR1B> 

CALL  FILEM< IFILE,ATRIB) 

RETURN 

END 

xxxxxmmxmxxmmsxssxmxxxmssss 

X  SUBROUTINE  'NXTSCP'  IS  USED  TO  X 

X  SCHEDULE  THE  ALERT  CREWS  FOR  ALL  X 
X  SCP  LAUNCH  CONTROL  CENTERS  X 

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 

SUBROUTINE  NXTSCP 

COMMON/SCCMl/ATRIB( 100) ,DD(  100) ,DDL(100) , DTNOW , 1 1 ,MFA ,MSTOP ,NCLNR 
1  ,NCRDR ,NPRNT ,NNRUN ,NNSET ,NTAPE ,SS(  100) ,SSL(100> ,TNEXT,TNOW,XX( 100) 
COMMON/UCCM1/IDAY,NXTDAY,IFILE,ISCHED( 100,32) ,DUMMY(14) ,LVBEG<3) ,L 
1VEND<3) ,INTFLT< 100) ,NOCRWS, NODAYS, NUMTRN,MAXLIN,MAXFCC,MAXSHP 


C0MM0N/UC0M5/SHPPCT , FCCPCT , FLTPCT , SHPCTS , FTPCTS , I STRM 1 , I STRM2 

THIS  SETS  THE  VARIABLE  'NEXT'  EQUAL  TO  THE 
FIRST  CREW  IN  THE  EA  QUEUE.  IF  'NEXT' 

EQUALS  8,  THEN  THE  CREW  FILE  IS  EMPTY.  IN 
THIS  CASE  A  WARNING  MESSAGE  IS  PRINTED  FOR 
THE  DAY  «WD  APPLICABLE  SCP.  A  DUMMY 
TRANSACTION  IS  THEN  USED  TO  INSURE  A  RETURN 
TO  THIS  SUBROUTINE  FOR  THE  FOLLOWING  DAYS 
ALERT  SCHEDULING 

NEXT=MMFE< 14) 

IF  (NEXT.EQ.8)  THEN 

WRITERS) '  CREW  FILE  EMPTY  ON  DAY  '  ,NXTDAY 
CALL  SCHDL( IFILE, 1 .0 , DUMMY) 

RETURN 

ENDIF 

THE  EA  QUEUE  IS  SEARCHED  FOR  A  SPECIFIC  SCP 
CREW  BASED  ON  THE  RANDOM  NUMBER  DRAWN  O'iD 
THE  SPECIFIED  PERCENTAGES 

RN=DRAND< ISTRM2) 

CALL  COPY (-NEXT, 14,ATRIB) 

IF  (RN.LE. SHPCTS)  THEN 

IF  <NINT<ATRIB< 4) )  .EQ.2  .AND.  NINT (ATRIBO) )  .EQ.  1)  THEN 
CALL  RMOVE(-NEXT, 16,ATRIB> 

CALL  FILEM< IFILE,ATRI8> 

RETURN 

ENDIF 

ELSE  IF  (RN.LE. FTPCTS)  THEN 

IF  <NINT<ATRIB<2>) .EQ.IFILE  .AND.  NINT(ATRIB<3) ) .EQ. 1)  THEN 
CALL  RMOVE<-NEXT,14,ATRIB) 

CALL  FILEM< IFILE,ATRIB) 

RETURN 

ENDIF 

ELSE 

IF  <NINT<ATRIB< 3)) .EQ.l  .AND.  NINT<ATRIB<4) ) .LT.2)  THEN 
CALL  RM0VE<-NEXT,14,ATRIB> 

CALL  FILEM(IFILE,ATRIB) 

RETURN 

ENDIF 

ENDIF 

NEXT=NSUCR  <  NEXT) 

IF  (NEXT .NE.8)  GO  TO  18 

IF  A  CREW  WITH  THE  REQUESTED  ATTRIBUTES  IS 
NOT  FOUND,  THEN  SEARCH  FILE  FOR  ANY  SCP  CREW 
IF  NO  SCP  CREWS  AVAILABLE  PRINT  WARNING  MESSAGE 
AND  SCHEDULE  DUMMY  TRANSACTION 

NEXT*MMFE< 14) 

IF  (NEXT.EQ.8)  THEN 

WRITE(4,X) '  NO  SCP  CREW  FOR  SCP  ' , IFILE, '  ON  DAY  ' ,NXTDAY 


v»V- 


< 


CALL  SCHDL( IFILE, 1 .0 , DUMMY) 

RETURN 

ENDIF 

CALL  COPY (-NEXT , 16,ATRIB> 

IF  (NINT(ATRIB(3) ) .EQ. 1)  THEN 
CALL  RMOVE ( -NEXT , 16 , ATRI B) 

CALL  FILEM( IFILE, ATRI 8) 

RETURN 

ENDIF 

N£XT=NSUCR(NEXT) 

GO  TO  28 
END 

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 
X  SUBROUTINE  'LEAVE'  CHECKS  THE  EA  X 
X  QUEUE  EACH  DAY  PRIOR  TO  SCHEDUL-  X 
X  ING  ALERTS  FOR  CREW  LEAVE  REQUESTS.  X 
X  CREWS  REQUESTING  LEAVE  WITHIN  THE  X 
X  NEXT  TWO  DAYS  ARE  REMOVED  FROM  THE  X 
X  EA  QUEUE  (FILE  16)  AND  PLACED  ON  THE  X 
X  EVENT  CALENDAR  FOR  RETURN  FOLLOWING  X 
X  LEAVE  COMPLETION  X 

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 


1  jNCRDRjNPW'JT ,M'JRUN,M'iSET ,NTAPE,SS(  108)  ,SSL(  10« 
COMMON/UCOM 1/1 DAY, NXTDAY, IFILE, ISCHED(  100,32)  , 
1VEND(3) , INTFLT ( 100) ,NOCRWS, NODAYS, NUMTRN,MAXLI 

SCHEDULE  THE  NEXT  LEAVE  SEARCH  TO  OCCUR  THE 
NEXT  DAY.  BEGIN  SEARCH  OF  THE  EA  QUEUE 
AND  COPY  LEAVE  START  AND  END  DATES  FOR  EACH 
CREW 

CALL  SCHDL( 30, 1.0, DUMMY) 

NEXT=MMFE( 16) 

IF  (NEXT.EQ.0)  RETURN 
CALL  COPY ( -NEXT , 16 , ATR I B) 

LVBEG(  1)=NINT(ATRIB(7) ) 

LVBEG(2)=NINT(ATRIB(?) ) 

LVBEG(3)«NINT(ATRIB( 1 1) ) 

LVEND( 1)=NINT(ATRIB(8)) 

LVEND(2)*NINT(ATRIB( 10) ) 

LVEND(3)=NINT(ATRIB( 12) ) 

IF  LEAVE  START  WITHIN  THE  NEXT  TWO  DAYS  FOUND 
REMOVE  CREW  AND  PLACE  ON  EVENT  CALENDAR  FOR 
RETURN  FOLLOWING  LEAVE  COMPLETION.  IN 
ADDITION,  UPDATE  SCHEDULING  ARRAY.  (NOTE: 
VARIABLE  'MOVE'  USED  TO  HOLD  POINTER  POSITION 
WHEN  CREW  REMOVED  FROM  THE  EA  QUEUE) 


DO  20  K*l,3 


m 


m 


IF  (LVBEGOO  .EQ.NXTDAY)  THEN 
DO  1  J=LVBEG(K) ,LVEND<K> 

ISCHED(NINT <ATRIB< 1) > ,J)=77 
CONTINUE 

DURLV=REAL ( LVEND ( K) -LVBEG  <  K>  )  + 1 . 2 
MOVE=NSUCR (NEXT) 

CALL  RMOVE<-NEXT, 16,ATRIB) 

CALL  SCHDL ( 25 , DURLV , ATR I B) 
NEXT=M0VE 
GO  TO  10 
ENDIF 

IF  (LVBEGOO .EQ.(NXTDAY+1>)  THEN 
DO  5  J=LVBEG(K) , LVEND  00 

ISCHED(NINT(ATRIB( D) ,J)=77 
CONTINUE 

DURLV=REAL ( LVEND  <  K) -LVBEGOO )  +2.2 
MOVE=NSUCR  <  NEXT) 

CALL  RMOVE(-NEXT, 16.ATRIB) 

CALL  SCHDL( 25, DURLV ,ATRIB) 
NEXT*MOVE 
GO  TO  18 
ENDIF 
CONTINUE 
NEXT=NSUCR<NEXT) 

GO  TO  10 
END 


xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 


SUBROUTINE  'LVUPDT'  IS  USED  TO 
UPDATE  THE  CREW  SCHEDULING  ARRAY 
FOR  THOSE  CREWS  WHO  HAVE  REACHED 
THEIR  MAXIMUM  ALERT  LOAD  BUT  STILL 
HAVE  LEAVE  REQUESTS  FOR  THE  REMAIN¬ 
DER  OF  THE  MONTH. 


xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 


SUBROUTINE  LVUPDT 

COMMON/SCQM 1/ATR I B < 100) ,DD< 100) ,DDL( 100) ,DTNOW, 1 1 ,MFA,MSTOP,NCLNR 
1 ,NCRDR ,NPRNT ,NNRUN ,NNSET ,NTAPE , SS< 100) ,SSL< 100) ,TNEXT,TNOW,XX( 100) 
CQMMON/UCQMl/IDAY ,NXTDAY , IFILE, ISCHEDC 100 ,32) ,DUMMY<14) ,LVBEG<3) ,L 
1VENDC3) ,INTFLT< 100) ,NOCRWS , NODAYS ,NUMTRN ,MAXLIN ,MAXFCC ,MAXSHP 


COPY  LEAVE  INFORMATION  FROM  CREW  ATIBUTES  AND 
UPDATE  CREW  SCHEDULING  ARRAY  IF  REQUIRED 


LVBEG( 1)=NINT  <ATRIB<7) ) 
LVBEG<  2) =NINT( ATRI B ( ?) ) 
LVBEG<3)=NINT(ATRIB<11)) 
LVEND ( 1)=NINT<ATRIB(8)) 
LVEND<2)=NINT<ATRIB( 10)) 
LVEND(3)=NINT  <ATRIB< 12) ) 

DO  5  K-1,3 

IF  < LVBEG< K) . GE . I DAY)  THEN 
DO  1  J=LVBEGOO  ,  LVEND  <K) 


A-49 


ISCHED<NINT<ATRIB< 1) ) ,J)=77 
CONTINUE 
ENDIF 
CONTINUE 
RETURN 
END 


XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 
X  SUBROUTINE  'OTPUT'  IS  CALLED  BY  SLAM  X 
X  WHEN  THE  ALERT  SCHEDULING  SIMULATION  X 
X  IS  COMPLETE.  THE  SUBROUTINES  FOR  X 
X  ASSIGNING  TRAINING  DAYS  fiNO  STATIS-  X 


TICS  COLLECTION  ARE  THEN  CALLED  FROM  X 


'OTPUT' .  FINALLY,  TRAINING  DATA, 
THE  CREW  SCHEDULE,  <*JD  MONTHLY  STA¬ 
TISTICS  ARE  PRINTED 


xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 


SUBROUTINE  OTPUT 

COMMON/SCOM 1/ATR I B < 108) ,DD< 100) ,DDL< 100) , DTNOW , 1 1 ,MFA ,MSTOP ,NCLNR 
1 ,NCRDR,NPRNT,NNRUN,NNSET,NTAPE,SS< 188) ,SSL<100) ,TNEXT,TNOW,XX< 180) 
COMMON/UCOM 1/ 1  DAY  ,NXTDAY ,  IFILE,ISCHED<  100,32)  ,Dl*MY<  14)  ,LUBE6<3)  ,L 
1VEND<3)  , INTFLT <  100)  ,NOCRWS , NODAYS  ,NIWTRN ,MAXLIN ,MAXFCC ,MAXSHP 
C0MM0N/UC0M2/ITRNDY<3, 15) ,ITYPE<3) ,MRKDAY<3) ,MPTDAY<31> ,NUMMPT ,MTB 
1MPT ,N,MAXCLS<3) ,MINCLS<3) 

COMMON/UCOM3/NOALTS< 100) ,FREDAY<  108) , INTALT< 108) ,LVDAYS< 108) 
C0MM0N/UC0M4/ALTMN , ALTSTD , ALT IMN , ALT I ST ,FREMN , FRESTD 
CHARACTER  F0RmT!4)X14,FMTlX14 


CALL  THE  'TRNING'  SUBROUTINE  FOR  EACH  TYPE 
OF  CLASSROOM  TRAINING.  CALL  THE  'MPTTRN' 
SUBROUTINE  FOR  SCHEDULING  TRAINER  RIDES 


DO  1  1=1 ,NUMTRN 
N=I 

CALL  TRNING 
CONTINUE 
CALL  MPTTRN 


ALL  SCHEDULING  FUNCTIONS  NOW  COMPLETE,  CALL 
'STATS'  SUBROUTINE  TO  GATHER  MONTHLY  STATISTICS 


CALL  STATS 


OUTPUT  CREW  SCHEDULING  MATRIX 


WRITE<6,X) 

WRITE<6,X) 'CREW  SCHEDULING  MATRIX' 

.  WRITE! 6, X) 

WRITE! 6, 100) 

F0W’1AT<7X,'  1'  ,3X,  '2'  ,3X, '3'  ,3X,  '4'  ,3X, '5'  ,3X,  '4'  ,3X, '7'  ,3X,  '8'  ,3X, 
1'?' ,2X,' 10' ,2X,'  11' ,2X,'  12, X,  13' ,2X,' 14' ,2X,' 15' ,2X,' 16' ,2X,' 17 
2',2X,'18',2X,'19',2X,'28',2X,'21',2X,'22',2X,'23',2X,'24',2X,'25', 
32X,'26',2X,'27',2X,'28',2X,'29',2X,'30',2X,'31') 


i OTP 


mu 


FORMAT < 1)='<29<I4>) ' 

F0RMAT<2)=' <38( 14)  > ' 

FORMAT  (3)S'(31(M))' 

F0RMAT<4)=' <32< 14) ) ' 

FMT l=FORMAT (NODAYS-27) 

WRITE<  6 , FMT 1) < I , < I SCHED< I ,  J)  ,  J=  1 , NODAYS) ,1=1 ,NOCRWS) 

WRITE<6,X) 

OUTPUT  MONTHLY  DATA  FOR  EACH  CREW 

WRITE<<4,X>'  MONTHLY  STATISTICAL  DATA:  ' 

WRITE<6,X) 

DO  5  1=1  ,NOCRWS 

WRITE<6,200) I ,NOALTS< I) ,INTALT(I> ,NINT(FREDAY< I) ) ,LVDAYS(I) 
CONTINUE 
WRITE<6,X) 

OUTPUT  MEAN  AND  STANDARD  DEVIATION  FOR  LINE 
CREW  DATA  TOTALS 

WRITE<6,X)'  NUMBER  OF  ALERTS : ' 

WRITE< 6 , 380) ALTMN , ALTSTD 

WRITE<6,X) '  NUMBER  OF  INTEGRAL  ALERTS : ' 

WRITE(6,300> ALTIMN,ALTIST 
WRITE(6,X) '  NUMBER  OF  FREE  DAYS:' 

WRITE< 6 , 300) FREMN , FRESTD 

FORMAT < '  CREW', 13,',  ALERTS' , 12, ' ,  INTEGRAL  ALERTS' ,12,' ,  FREE  DAY 
IS', I 3,',  ACTUAL  NUMBER  OF  LEAVE  DAYS  ',13) 

FORMAT < '  MEAN  =' , F7. 3, 5X, 'STANDARD  DEVIATION  =',F8.5,/> 

RETURN 

END 

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 
X  SUBROUTINE  'TRNING'  ASSIGNS  CREWS  TO  X 
X  CLASSROOM  TRAINING  REQUIREMENTS.  UP  X 
X  TO  THREE  TYPES  OF  CLASSROOM  TRAINING  X 
X  my  BE  SCHEDULED.  THE  SUBROUTINE  X 
X  SCHEDULES  UP  TO  80X  OF  THE  httXIMUM  X 
X  CLASS  SIZE  ON  THE  FIRST  PASS  THROUGH  X 
X  THE  CREW  FORCE,  A  SECOND  PASS  IS  THENX 
X  MADE  STARTING  FROM  THE  LAST  AVAIL-  X 
X  ABLE  TRAINING  DAY  TO  FILL  UP  TO  THE  X 
X  MAXIMUM  CLASS  SIZE.  NO  CLASSES  ARE  X 
X  SCHEDULED  FOR  LESS  THAN  THE  MINIMUM  X 
X  CLASS  SIZE  AND  A  WARNING  IS  PRINTED  X 
X  FOR  ANY  CREWS  NOT  SCHEDULED  FOR  EACH  X 
X  TYPE  OF  TRAINING  X 

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 

SUBROUTINE  TRNING 

COMMON/SCOMl/ATRIB< 188) ,DD< 180) ,DDL( 188) , DTNOW , 1 1 ,MFA ,MSTOP ,NCLNR 
1  ,NCRDR ,NPRNT , WRUN ,NNSET ,NTAPE , SS<  180)  ,SL  18)  ,TNEXT ,TNOW,XX<  108) 
COMMON/UCOMl/IDAY,NXTDAY, IFILE, ISCHED< 180 ,32) ,DLMMY< 14) ,LVBEG<3) ,L 
1 VEND (3) ,INTFLT< 188) ,NQCRWS , NODAYS ,NLWTW4  ,MAXL IN .MAXFCC ,MAXSHP 


COMMON/UCOM2/ITRNDY<3, 15) ,ITYPE<3) ,MRKDAY<3) ,MPTDAY<31> ,NLMiPT,MTB 
1MPT,N,MAXCLS<3) ,MINCLS<3> 

LOGICAL  NOSCHD( 108) 

DIMENSION  ICREWC25) , ICOUNT ( 15) 

INITIALIZE  SUBROUTINE  PECULIAR  ARRAYS 

DO  1  1=1,15 
I COUNT  <  I )  =0 
CONTINUE 
DO  2  1=1,190 

NOSCHD<I)=.TRUE. 

CONTINUE 
DO  3  1=1,25 
I CREW < I)=0 
CONTINUE 

BEGIN  SEARCH  OF  THE  CREW  FORCE  FOR  EACH 
AVAILABLE  TRAINING  DAY  BEGINNING  WITH  THE 

FIRST  AVAILABLE  DAY.  ( ' ITDAY'  IS  THE  TRAINING  DAY  BEING  CHECKED) 
DO  5  J=1 , 15 

ITDAY=ITRNDY< ITYPE(N) ,J) 

IF  (ITDAY.EQ.0)  GO  TO  50 
DO  10  1= 1 ,NOCRWS 

LOGICAL  ARRAY  'NOSCHED'  IS  USED  TO  RECORD 
WHETHER  CREW  'I'  HAS  BEEN  SCHEDULED  FOR  THIS 
TRAINING,  .TRUE.  INDICATES  CREW  t*S  NOT  BEEN 
SCHEDULED.  IF  CREW  HAS  NOT  BEEN  SCHEDULED 
FOR  THIS  TRAINING  AND  IS  NOT  SCHEDULED  FOR 
ANY  OTHER  ACTIVITY,  THEN  INCREASE  COUNT  AND 
RECORD  CREW  NUMBER  IN  'I CREW'  FOR  THIS  DAY. 

IF  <NOSCHD( I) .AND. ISCHED( I , ITDAY) .EQ.0)  THEN 

I COUNT < J) = I COUNT ( J) + 1 

ICREW<ICOUNT<J))=I 

ENDIF 

AS  SOON  AS  THE  COUNT  REACHES  80/'.  OF  THE 
MAXIMUM  CLASS  SIZE,  SCHEDULE  THOSE  CREWS  BY 
UPDATING  THE  SCHEDULING  ARRAY  f*ID  CHANGE 
'NOSCHED'  TO  .FALSE.  PROCEED  TO  NEXT  AVAIL¬ 
ABLE  TRAINING  DAY 

IF  <ICOUNT<J) .EQ.NINT(.8XMAXCLS<N)))  THEN 
DO  15  K=  1 , ICOUNT< J) 

I SCHED( I CREW<  K) , ITDAY) =MRKDAY<N) 

NOSCHD  < I CREW  <  K) )  =  . FALSE . 

CONTINUE 
GO  TO  5 
ENDIF 
CONTINUE 


IF  80X  OF  MAX  SIZE  t«WS  NOT  REACHED  BUT  MINIMUM 
CLASS  SIZE  l»MS  REACHED,  THEN  SCHEDULE  THOSE 
CREWS 

IF  < ICOUNT< J) .GE.MINCLS(N) )  THEN 
DO  20  K=l,ICOUNT(J) 

ISCHED( ICREW<K) , ITDAY) =MRKDAY<N) 

NQSCHDC I CREW  <K)  )  =  . FALSE . 

CONTINUE 

ENDIF 

CONTINUE 

BEGIN  SECOND  SEARCH  OF  CREW  FORCE  STARTING  WITH 
LAST  AVAILABLE  DAY  AND  SCHEDULE  UP  TO  THE 
MAXIMUM  CLASS  SIZE 

DO  25  1=1 ,NOCRWS 

IF  <NOSCHD< I) )  THEN 
DO  38  J= 15, 1,-1 
ITDAY=ITRNDY< ITYPE<N) ,J) 

IF  ( ITDAY. EQ.0)  GO  TO  30 
IF  <ICOUNT<J) .LT.MINCLS(N) )  GO  TO  30 

IF  (ICOUNT(J) .LT.MAXCLS(N)  .AND.  ISCHEDt I , ITDAY) .EQ.0)  THEN 
I COUNT < J) = I COUNT < J> + 1 
ISCHED< I , ITDAY) =MRKDAY<N) 

NOSCHD<I)=. FALSE. 

GO  TO  25 
ENDIF 
CONTINUE 
ENDIF 
CONTINUE 

PRINT  ANY  CREW  NOT  SCHEDULED  FOR  TRAINING 

DO  35  1=1 ,NOCRWS 

IF  (NOSCHD< I) )  THEN 

WRITE<6, 100) I ,MRKDAY<N> 

ENDIF 

CONTINUE 

PRINT  RECAP  OF  TRAINING  DAYS  USED  AND  THE 
NUMBER  OF  CREWS  SCHEDULED  FOR  EACH  DAY 

DO  40  1=1,15 

IF  (ICOUNTU)  .GT.<MINCLS<N)-1))  THEN 

WR ITE ( 6 , 20 0 ) MRKDAY <N)  ,  ITRNDYC ITYPE(N)  ,1)  ,  ICOUNTU) 

ENDIF 

CONTINUE 

FORMAT < '  CREW' ,13/  NOT  SCHEDULED  FOR', 1 3,'  TRAINING') 

FORMAT  < '  FOR', 13,'  TRAINING  ON  DAY' ,13,' ,' ,13,'  CREWS  SCHEDULED) 

RETURN 

END 


xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

X  SUBROUTINE  'MPTTRN'  IS  USED  TO  X 

X  SCHEDULE  CREWS  FOR  UP  TO  TWO  HPT  X 
X  PERIODS  PER  MONTH.  WHEN  SCHEDULING  X 
X  MORE  THAN  ONE  MPT,  A  USER  SPECIFIED  X 
X  MINIMUM  TIME  BETWEEN  MPTS  < "MTBMPT")  X 
X  IS  USED  FOR  TRAINING  SEPARATION  X 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

SUBROUTINE  MPTTRN 

COMMON/SCQMl/ATRIB< 188) ,DD<100) ,DDL(100> , DTNCW , 1 1 ,MFA ,MSTOP ,NCLNR 
1  ,NCRDR  ,NPRNT ,M'JRUN,I'NSET,NTAPE,SS(  100)  ,SSL<  100)  ,TNEXT,TNOW,XX(  108) 
COMMON/UCOMl/IDAY,NXTDAY, IFILE, ISCHED< 100,32) ,DUM1Y< 14) ,LVBEG<3) ,L 
1VENDI3) , INTFLT  < 100) ,NOCRWS , NODAYS ,NUMTRN ,MAXL IN ,MAXFCC ,MAXSHP 
C0MM0N/UC0M2/ I TRNDY ( 3 , 15) ,ITYPE(3) ,MRKDAY<3) ,MPTDAY(31) ,NUMMPT,MTB 
1MPT ,N ,MAXCLS ( 3) ,MINCLS<3) 

DIMENSION  MPTSCH< 100,2) ,N0ASGN<31) 

INITIALIZE  SUBROUTINE  PECULIAR  ARRAYS 

DO  1  1=1,108 
DO  2  J= 1 , 2 
MPTSCH( I , J)=0 
CONTINUE 
CONTINUE 
DO  3  1=1,31 
NOASGNC I)=0 
CONTINUE 

BEGIN  SEARCH  OF  CREW  FORCE  FOR  THE  NUMBER  OF 
MPTS  SPECIFIED.  SEARCH  BEGINS  WITH  THE 
LARGEST  CREW  NUMBER  AND  WORKS  BACKWARDS 
EACH  CREW  IS  CHECKED  AGAINST  ALL  DAYS  BEFORE 
MOWING  TO  THE  NEXT  CREW 

DO  5  K=1 jNUMMPT 

DO  10  I=NOCRWS,  1,-1 
DO  15  J=l, NODAYS 

COMPARE  THE  NUMBER  OF  AVAILABLE  MPT  PERIODS  FOR 
DAY  'J'  TO  THE  NUMBER  OF  CREWS  ASSIGNED  ON  THAT  DAY 

IF  (MPTDAY(J) .EQ.NOASGN(J))  GO  TO  15 

IF  CREW  IS  AVAILABLE  THEN  SCHEDULE  FOR  MPT 
IF  THIS  IS  THE  SECOND  MPT  THEN  INSURE  MINIMUM 
TIME  BETWEEN  MPTS  IS  SATISFIED  PRIOR  TO 
SCHEDULING  CREW 

IF  ( ISCHEDI I , J) .EQ.0  .AND.  MPTSCH< I ,K) .EQ.9)  THEN 

IF  <K.EQ.2.AND.ABS(J-MPTSCH< 1,1)) .LT.MTBMPT)  GOTO  15 
ISCHED( I , J)=46 
MPTSCH< I ,K)=J 


NOASGN ( J) =NOASGN (J)  +  l 
GO  TO  18 
ENDIF 
CONTINUE 

PRINT  CREWS  NOT  SCHEDULED  FOR  EACH  MPT  SESSION 

WRITE(6,X)'  CREW  ',1,'  NOT  SCHEDULED  FOR  MPT  ' ,K 
CONTINUE 
CONTINUE 
RETURN 
END 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

X  SUBROUTINE  'STATS'  COLLECTS  INDIVID-  X 
X  UAL  CREW  STATISTICS  AND  CUMULATIVE  X 
X  STATISTICS  ON  LINE  CREWS.  DATA  IS  X 
X  TAKEN  FROM  THE  CREW  SCHEDULING  ARRAY  X 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

SUBROUTINE  STATS 

COMMON/UCOMl/IDAY,NXTDAY , IFILE, ISCHED( 180 ,32) ,DLMMY( 14) ,LVBEG(3) ,L 
1VEND( 3) , INTFLT  < 108) ,NOCRWS , NODAYS ,NUMTRN ,MAXLIN ,MAXFCC ,MAXSHP 
C0MM0N/UC0M3/N0ALT  S  ( 180) ,FREDAY<  100) , INTALT< 100) ,LVDAYS( 108) 
COMMON/UCOM4/ALTMN , ALTSTD , ALT IMN , ALT I ST , FREMN , FRESTD 

INITIALIZE  SUBROUTINE  PECULIAR  ARRAYS  M  VARIABLES 

DATA  NOALTS/ 108X0/ 

DATA  FREDAY/ 100X0/ 

DATA  INTALT/ 100X0/ 

ALTMN=0 . 0 
ALTSTD=0.0 
ALTIMN=0 .0 
ALTIST=0 .0 
FREMN=0 .0 
FRESTD=0 .0 
CREWS=0 . 0 

COLLECT  DATA  ON  NUMBER  OF  ALERTS,  NUMBER  OF 
INTEGRAL  ALERTS  AND  NUMBER  OF  FREE  DAYS  FOR 
EACH  CREW.  (NOTE:  ACTUAL  LEAVE  DAYS  ARE 
ADDED  TO  FREE  DAYS) 

DO  5  1=1 ,N0CRW3 
DO  10  J=l, NODAYS 

IF  (ISCHEDd  ,J)  .GT.8  .fWD.  ISCHED< I , J)  ,LE.  15)  THEN 
NOALTS< I)=NOALTS< I) + 1 
IF  <ABS< INTFLT< I) >  .EQ. ISCHEDd  ,J))  THEN 
INTALTd)=INTALT(I)  + 1 
ENDIF 

ELSE  IF  (ISCHEDd  ,J)  .EQ.0)  THEN 
FREDAY ( I ) =FREDAY (I ) + 1 


10  CONTINUE 

FREDA Y  <  I )  =FREDAY  (.  I)  +LVDAYSC I> 

5  CONTINUE 

C 

C  COLLECT  CUMULATIVE  STATISTICS  FOR  LINE  CREWS 
C  ONLY.  DATA  CONTAINED  IN  ARRAY  ' INTFLT'  IS 

C  USED  TO  SEPARATE  LINE  CREWS  FROM  FLIGHT 

C  COMMANDERS,  CODED  AS  NEGATIVE  NUMBERS,  FWD 

C  DOV/DOT  CREWS,  CODED  AS  16  AND  17 

C 

DO  15  1=1 ,NOCRWS 

IF  < INTFLT (I) .GT.0  .AND.  INTFLT(I) .LE. 15)  THEN 
ALTMN=ALTMN+REAL<NOALTS( I) ) 

ALTSTD=ALTSTD+ REAL  <NOALTS( I) **2> 

ALTIK  =ALTIW+REAL(INTALT(I)) 

ALT I ST=ALT I ST+REAL (I NT ALT < I) X  X  2) 
FREMN=FREMN+ FREDAY ( I ) 

FRESTD=FRESTD+FREDAY ( I) X*2 
CREWS=CREWS+ 1 
ENDIF 
15  CONTINUE 

C 

C  COMPUTE  MEAN  AND  STANDARD  DEVIATION  FOR 

C  CUMULATIVE  STATISTICS 

C 

ALTTt'NALTMN/  CREWS 

ALTSTD= (ALTSTD-CREWSX ALTMNX *2>  /< CREWS- 1 > 

IF  (ALTSTD . GT . 8 . 0)  ALTSTD=SQRT (ALTSTD) 
ALTIMN=ALTIMN/CREWS 

ALT I ST=  <  ALT I ST-CREWS* ALT I MNXX  2) / (  CREWS- 1 ) 

IF  (ALTIST.GT.0.0)  ALTI ST=SQRT (ALTI ST) 
FREMN=FREMN/CREWS 

FRESTD=(FRESTD-CREWSXFREMNXX2> /( CREWS- 1) 

IF  (FRESTD.GT.0.0)  FRESTD=SQRT < FRESTD) 

RETURN 

END 


LIST  OF  VARIABLES;  SLAM  SCHEDULING  PROGRAM 


ARRAYS 


DUMMY<14)  -  zero  array;  real 

F0RMAT<4)  -  stores  Format  parameters  For  output  oF  scheduling  array; 
character 

FREDAY< 100)  -  number  oF  Free  days  For  each  crew;  real 

IC0UNT<15>  -  number  oF  crews  selected  For  classroom  type  training  on 
given  day;  integer 


ICREWC25)  -  crew  numbers  of  crews  assigned  to  classroom  training  on  a 
particular  day;  integer 

INTALT<100)  -  number  o-f  integral  -flight  alerts  for  each  crew;  integer 

INTFLT<100)  -  stores  coded  flight  assignment  data  for  each  crew;  integer 

ISCHED(  100 ,32)  -  crew  scheduling  matrix;  integer 

ITRNDY<3,15)  -  available  training  days  for  each  type  of  classroom 
training;  integer 

ITYPE<3)  -  identifies  type  of  classroom  training;  integer 

LVBEG(3)  -  begin  leave  dates  for  each  crew,  attributes  7,  9,  11;  integer 

LVEND(3)  -  end  leave  dates  for  each  crew,  attributes  8,  10,  12;  integer 

LVDAYSC 100)  -  number  of  actual  leave  days  per  crew;  integer 

MAXCLS<3)  -  maximum  class  size  for  each  type  classroom  training;  integer 

MINCLS<3)  -  minimum  class  size  for  each  type  classroom  training;  integer 

MPTDAY<31)  -  number  of  available  MPT  sessions  per  day;  integer 

MPTSCH( 100,2)  -  date  of  assignment  for  each  MPT  session  by  crew  number; 
integer 

MRKDAY<3)  -  numeric  code  of  each  type  classroom  training;  integer 
NOALTSt 100)  -  number  of  alerts  for  each  crew;  integer 
N0ASGN<31)  -  number  of  crews  actually  assigned  to  MPT  per  day;  integer 
NOSCHD< 100)  -  crews  not  scheduled  for  classroom  training;  logical 

VARIABLES 

ALTIMN  -  mean  number  of  integral  alerts;  real 
ALTIST  -  integral  alert  standard  deviation;  real 
ALTMN  -  mean  number  of  alerts;  real 


ALTSTD  -  alert  standard  deviation;  real 
CREWS  -  number  of  line  crews;  real 
DURLV  -  duration  of  leave  period;  real 


FCCPCT  -  percentage  of  -flight  commanders  sent  to  non-SCP  alerts;  real 


FLTPCT  -  percentage  of  crews  sent  to  their  assigned  flight  for  nor-SCP 
alerts;  real 

FMT1  -  output  format;  character 
FREMN  -  mean  number  of  free  days;  real 
FRESTD  -  free  days  standard  deviation;  real 

FTPCTS  -  percentage  of  crews  sent  to  their  assigned  flight  for  SCP 
alerts;  real 

IDAY  -  integer  representation  of  SLAM  variable  TNOW;  integer 
IFILE  -  alert  queue  identifier;  integer 

ISTRM1  -  random  number  stream  used  for  non-SCP  alerts;  integer 

ISTRM2  -  random  number  stream  used  for  SCP  alerts;  integer 

ITDAY  -  classroom  training  day  under  consideration;  integer 

MAXFCC  -  maximum  number  of  alerts  for  flight  commander;  integer 

MAXLIN  -  maximum  number  of  alerts  for  line  crews;  integer 

MAXSHP  -  maximum  number  of  alerts  for  DOV/DOT  crews;  integer 

MOVE  -  temporary  pointer  holder  in  subroutine  LEAVE;  integer 

MTBMPT  -  minimum  time  between  MPT  training;  integer 

N  -  identifies  type  classroom  training;  integer 

NEXT  -  pointer  used  when  searching  EA  queue;  integer 

NOCRWS  -  total  number  of  crews;  integer 

NODAYS  -  number  of  days  in  month;  integer 

NUMMPT  -  number  of  MPT  sessions  requested  per  crew;  integer 

NUMTRN  -  number  of  classroom  type  training;  integer 

NXTDAY  -  I DAY  +  i;  integer 

RN  -  random  number  drawn  by  SLAM  function  DRAND;  real 

SHPCTS  -  percentage  of  DOV/DOT  crews  sent  to  SCP  alerts;  real 

SHPPCT  -  percentage  of  DOV/DOT  crews  sent  to  non-SCP  alerts;  real 


APPENDIX  B 


This  appendix  contains  the  data  and  calculations  used  in 
the  experiments  and  sensitivity  analysis  presented  in  Chap¬ 
ter  IV.  Note  that  the  alpha  level  -for  all  statistical  tests 
used  in  this  appendix  is  0.05. 
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Table  8-1.  Data  Points  ■for  Factors  One,  Two,  and  Three 
versus  Perm-f orman ce  Measure  One 


Factor  Three 

Factor  One 

PM  1 

PM2 

PM3 

0.0 

0.0 

0.910 

8.826 

0.775 

0.0 

0.1 

0.910 

8.825 

0.777 

0.0 

0.2 

0.920 

0.830 

0.780 

0.0 

0.3 

0.910 

0.835 

0.793 

0.0 

0.4 

0.910 

0.838 

0.795 

0.0 

0.5 

0.913 

8.838 

0.788 

0.1 

0.1 

0.915 

0.841 

0.803 

0.1 

0.3 

0.918 

0.866 

0.836 

0.1 

0.5 

8.918 

8.858 

0.818 

0.2 

0.0 

0.910 

8.858 

0.820 

0.2 

0.2 

0.928 

0.860 

0.829 

0.2 

0.3 

0.923 

0.858 

0.829 

0.2 

0.4 

0.924 

0.865 

0.833 

0.2 

0.5 

0.930 

0.868 

0.838 

0.3 

0.1 

0.930 

0.878 

0.848 

0.3 

0.3 

0.940 

0.875 

0.850 

0.4 

0.1 

0.936 

0.884 

0.862 

0.4 

0.2 

0.941 

0.892 

0.878 

0.4 

0.3 

0.942 

0.891 

0.875 

0.4 

0.4 

0.943 

0.900 

0.883 

0.4 

0.5 

0.940 

0.886 

0.858 

0.5 

0.1 

0.944 

0.900 

0.886 

0.5 

0.2 

0.944 

0.898 

0.878 

0.5 

0.3 

0.944 

0.898 

0.882 

0.5 

0.4 

0.942 

0.892 

0.878 

0.5 

0.5 

0.940 

0.888 

0.868 

0.6 

0.1 

0.955 

0.919 

0.908 

0.6 

0.2 

0.958 

0.929 

0.928 

0.6 

0.3 

0.959 

0.929 

0.925 

0.7 

0.1 

0.958 

0.932 

0.930 

0.7 

0.2 

0.950 

0.932 

0.930 

0.7 

0.3 

0.958 

8.931 

0.928 

0.8 

0.0 

0.871 

0.860 

0.853 

0.8 

0.1 

0.956 

0.948 

0.956 

0.8 

0.2 

8.961 

0.951 

0.955 

0.9 

0.0 

0.932 

0.924 

0.924 

0.9 

0.1 

0.934 

0.924 

0.926 

1.0 

0.0 

0.890 

0.879 

0.874 
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Table  B-3.  Data  Points  for  Factor  Three  and 

Factor  Two  versus  Performance  Measures 
One,  Two  and  Three 


Factor  Three 

Factor  Two 

PM  1 

PM2 

PM3 

0.0 

8.5 

0.913 

0.838 

0.788 

0.8 

0.6 

0.910 

0.838 

0.795 

0.0 

8.7 

0.917 

0.838 

0.798 

0.0 

8.8 

0.910 

0.825 

0.773 

0.0 

0.9 

0.910 

0.825 

0.777 

0.0 

1.0 

0.910 

0.828 

0.778 

0.1 

0.3 

0.920 

0.848 

0.813 

0.1 

0.5 

0.920 

0.850 

0.812 

0.1 

0.6 

0.916 

0.838 

0.800 

0.1 

0.8 

0.915 

0.848 

0.808 

8.2 

8.3 

0.915 

0.868 

0.838 

8.2 

0.4 

0.930 

0.858 

0.825 

8.2 

0.5 

0.925 

0.858 

0.828 

8.2 

0.6 

0.930 

0.860 

0.830 

8.2 

0.8 

0.910 

0.358 

0.820 

0.3 

0.3 

0.940 

0.875 

0.850 

0.3 

0.6 

0.930 

0.878 

0.848 

0.4 

0.1 

0.940 

0.886 

0.858 

0.4 

0.2 

0.941 

0.893 

0.878 

0.4 

0.3 

8.942 

0.891 

0.875 

0.4 

0.4 

0.941 

0.895 

0.880 

0.4 

0.5 

0.936 

0.884 

0.862 

0.5 

0.0 

0.938 

0.888 

0.868 

0.5 

0.1 

0.942 

0.892 

0.878 

0.5 

0.2 

0.944 

0.898 

0.882 

0.5 

8.3 

0.944 

0.898 

0.878 

0.5 

0.4 

0.944 

0.900 

0.886 

0.6 

0.1 

0.957 

0.922 

0.912 

0.6 

0.2 

8.958 

0.929 

0.928 

0.6 

0.3 

8.955 

0.922 

0.916 

8.7 

0.0 

0.958 

0.931 

0.928 

0.7 

0.1 

0.960 

0.932 

0.932 

8.7 

0.2 

0.958 

0.932 

0.930 

0.8 

8.0 

0.934 

0.923 

0.923 

0.8 

0.1 

0.964 

0.948 

0 .956 

0.8 

0.2 

0.875 

0.865 

0.863 

0.9 

0.0 

0.933 

0.924 

0.926 

0.9 

0.1 

0.932 

0.924 

0.924 

1.0 

0.0 

0.890 

0.879 

0.874 
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Table  B-4.  Best  Data  Points  -for  Factors 

One,  Two,  and  Three  -for  Performance 
Measure  One 


Factor 

Number  of 

Data 

Points 

PM  1 

Level 

Observations 

FI 

F2 

F3 

Mean 

Variance 

1 

18 

8.1 

8.1 

8 .6 

8.954 

4.87E-5 

2 

18 

8.1 

8.3 

8.6 

8.955 

2.82E-5 

3 

18 

8.1 

8.2 

8.7 

8.958 

4.89E-5 

4 

14 

8.1 

8.1 

8.8 

8.964 

2.42E-5 

3 

18 

8.1 

s> 

a 

CD 

8.9 

8.933 

4.75E-5 

6 

18 

8.2 

8.2 

8.6 

8.958 

6. 19E-5 

7 

12 

8.2 

8.1 

8.7 

8.968 

7.38E-5 

8 

18 

8.2 

8.8 

8.8 

8.961 

9.85E-5 

9 

18 

8.3 

8.1 

8.6 

8.959 

9.54E-6 

18 

12 

8.3 

. 

CD 

8.7 

8.958 

3.35E-5 

ANALYSIS  FOR  FACTORS  ONE,  TWO,  AND  THREE 


The  ten  -factor  levels  were  compared  to  check  -for  signi¬ 
ficant  differences  in  the  means.  First  the  variances  of  the 
factor  levels  were  compared.  If  the  variances  could  be  con¬ 
sidered  equivalent  by  using  an  F-test,  the  means  were  check¬ 
ed  using  a  T-test.  If  the  variances  could  not  be  considered 
equivalent  then  a  Wi 1 coxon-Mann-Whi tney  rank  sum  test  was 
used  to  test  for  a  difference  in  the  means.  The  results  are 
presented  in  Table  B-5.  Factor  level  four  had  the  highest 
mean,  therefore  all  other  factor  levels  were  compared  to  it. 
The  mean  for  factor  level  four  was  0.964  and  the  variance 
was  2.42E-5.  Only  factor  level  eight  had  to  be  tested  with 
the  rank  sum  test.  The  results  of  this  test  showed  that 
there  was  no  significant  difference  in  the  means  of  factor 
levels  four  and  eight.  These  two  factor  levels  <.1,.1,.8 
and  .2,0,. 8)  are  the  best  levels  for  factors  one,  two,  and 
three  for  performance  measure  one. 


Table  B-5.  Analysis  for  Factors  One,  Two,  and 
Three  for  Performance  Measure  One 


Factor 

Mean 

Variance 

D.F. 

Computed 

D.F. 

Computed 

Level 

F-val ue 

T-val  ue 

1 

0.954 

4.87E-5 

9,13 

2.01 

22 

-13.27 

2 

0.955 

2.82E-5 

9,13 

1.17 

22 

-14.08 

3 

0.958 

4.09E-5 

9,13 

1.69 

22 

-8.42 

5 

0.933 

4.75E-5 

9,13 

1.96 

22 

-41.47 

6 

0.958 

6. 19E-5 

13,  17 

2.56 

30 

-9.94 

7 

0.960 

7.30E-5 

11,13 

3.02 

24 

-5.05 

8 

0.961 

9.85E-5 

)K 

M 

c 

* 

a 

rank  sum 

test** 

9 

0.959 

9.54E-6 

9,13 

2.54 

22 

-9.75 

10 

0.958 

3.35E-5 

11,13 

1.38 

24 

-9.84 
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Table  B-6.  Best  Data  Points  for  Factors 

One,  Two,  and  Three  for  Performance 
Measure  Two 


Fac  tor 

Number  of 

Data 

Points 

PM  1 

Level 

Observations 

FI 

F2 

F3 

Mean 

Variance 

1 

10 

0.1 

0.1 

0.6 

0.915 

9.39E-5 

2 

10 

0.1 

0.3 

0.6 

0.922 

8.43E-5 

3 

10 

0.1 

0.2 

0.7 

0.932 

4.83E-5 

4 

14 

0.1 

0.1 

0.8 

0.948 

1.79E-5 

5 

10 

0. 1 

0.0 

0.9 

0.924 

1. 16E-4 

6 

18 

0.2 

0.2 

0.6 

0.929 

1.74E-5 

7 

12 

0.2 

0.1 

0.7 

0.932 

1.76E-4 

8 

10 

0.2 

0.0 

0.8 

0.951 

5.47E-5 

9 

10 

0.3 

0.1 

0.6 

0.929 

9.54E-6 

10 

12 

0.3 

0.0 

0.7 

0.931 

8.10E-5 

In  the  analysis  for  this  performance  measure,  factor 
level  eight  has  the  highest  mean  (0.951)  with  a  variance  of 
5.47E-5.  All  other  factor  levels  were  compared  to  level 
eight.  Factor  levels  four,  six,  and  nine  had  to  be  tested 
with  the  rank  sum  test.  The  results  are  summarized  in 
Tables  B-7  and  B-8.  Once  again  factor  levels  four  and  eight 
were  found  to  be  the  best  levels  for  factor  one,  two,  and 


three 
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Table  B-7.  Analysis  -for  Factors  One,  Two,  and 
Three  -for  Performance  Measure  Two 


Factor 

Mean 

Variance 

D.F. 

Computed 

D.F. 

Computed 

Level 

F-val ue 

T-val  ue 

1 

0.915 

9.39E-5 

9,9 

1.72 

18 

-28.02 

2 

0.922 

8.43E-5 

9,9 

1.54 

18 

-23.33 

3 

0.932 

4.83E-5 

9,9 

1.13 

18 

-17.76 

4 

0.948 

1.79E-5 

** Used 

rank  sum 

test** 

5 

0.924 

1. 16E-4 

9,9 

2.12 

18 

-19.61 

6 

0.929 

1.74E-5 

SSUsed 

rank  sum 

test 

7 

0.932 

1.76E-4 

9,11 

3.22 

20 

-13.07 

9 

0.929 

9.54E-6 

SSUsed 

rank  sum 

test** 

10 

0.931 

8. 10E-5 

9,11 

1.48 

20 

-17.93 

Table  B-8.  Rank  Sum  Test  Results  for  Factors 

One,  Two,  and  Three  and  Performance 
Measure  Two 


Factor 

Expected 

Variance 

Sum  of  D.F 

.  Computed 

Level 

Val  ue 

Ranks 

Z-val ue 

4 

125 

291.67 

136. 

5  22 

-0.673 

6 

261 

435 

171 

30 

-4.32 

9 

105 

175 

55 

22 

-3.78 

Table  B- 

-9.  Best 

Data  Points 

for 

Factors 

One, 

Two,  and  Three  for  Performance 

Measure  Three 

Factor 

Number 

of  Data 

Points 

PM  1 

~i 

Level 

Observations  FI 

F2 

F3 

Mean  Variance 

1 

10 

0. 1 

0.1 

0.6 

0.899 

l .34E-3 

2 

10 

0.1 

0.3 

0.6 

0.916 

2.05E-4 

3 

10 

0. 1 

0.2 

0.7 

0.930 

1.78E-4 

4 

14 

0.1 

0.1 

0  .8 

8.956 

2.38E-5 

5 

10 

0.1 

0.0 

0.9 

8.926 

2.04E-4 

6 

18 

0.2 

0.2 

0.6 

0.928 

6.93E-5 

7 

12 

0.2 

0.1 

0.7 

0.932 

2.51E-4 

8 

10 

0.2 

0.0 

0.8 

0.955 

5.00E-5 

9 

10 

0.3 

0.1 

0.6 

0.925 

5.07E-5 

10 

12 

0.3 

0.0 

0.7 

0.928 

1.79E-4 

B- 

8 

.  •J-'.v.'.C 

Factor  level  four  has  the  highest  mean  for  performance 
measure  three  <0.?56>  with  a  variance  of  2.38E-5.  Only  two 
factor  levels  can  be  compared  without  using  a  rank  sum  test, 
factor  levels  8  and  9.  The  results  of  the  analysis  are  pre¬ 
sented  in  Tables  B-10  and  B-il.  The  results  show,  once 
again,  that  factor  levels  four  and  eight  are  the  best  levels 
for  performance  measrue  three.  These  results  indicate  that 
the  same  factor  levels  can  be  used  for  all  three  performance 
measures. 
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Table  B-12.  Factor 
Three 
Five 


Factor 

Level 

Factor  1 

Data  Points 
Factor  2 

Factor  3 

1 

0.1 

0.2 

0.7 

2 

0.2 

0.1 

8.7 

3 

8.3 

0.0 

0.7 

4 

0.1 

0.4 

0.5 

5 

0.4 

0.1 

0.5 

6 

0.2 

0.3 

0.5 

7 

0.3 

0.2 

8.5 

8 

0.5 

0.0 

0.5 

9 

0.1 

0.5 

0.4 

10 

0.5 

0.1 

0.4 

Table  B-13. 

Factor  Levels  for  Factors  Four  and  Five 

Used  in  Finding  the  Best  Factor  Four  and 

Five  Levels 

Factor 

Data 

Points 

Level 

Factor  4 

Factor  5 

1 

0.1 

0.9 

2 

0.2 

0.8 

3 

0.3 

0.7 

4 

0.4 

0.6 

5 

0.6 

0.4 

6 

CD 

• 

00 

0.2 

7 

1.0 

0.0 

Table  B-14.  Results  From  Data  Runs  -for  Factors  Four 
and  Five  -for  Performance  Measure  One 


Factors  4  and 

5  Levels 

Factors 

1,2, and  3 

1 

2 

3 

4 

5 

6 

7 

Level  s 

1 

0.96 

0.97 

0.96 

0.96 

0.96 

0.95 

0.95 

2 

0.96 

0.96 

0.96 

0.95 

0.95 

0.95 

0.95 

3 

0.96 

0.96 

0.96 

0.94 

0.95 

0.95 

0.96 

4 

0.95 

0.97 

0.96 

0.94 

0.94 

0.94 

0.94 

5 

0.95 

0.95 

0.95 

0.94 

0.94 

0.94 

0.94 

6 

8.95 

0.95 

0.95 

0.94 

0.95 

8.94 

8.94 

7 

0.95 

0.95 

0.95 

0.94 

0.94 

0.95 

0.95 

8 

0.95 

0.95 

0.94 

0.94 

0.94 

0.94 

8.93 

9 

0.95 

0.95 

0.94 

0.94 

0.93 

0.93 

0.93 

10 

0.95 

0.95 

0.94 

0.94 

0.94 

0.93 

8.94 

Mean 

.953 

.956 

.951 

.943 

.944 

.942 

.943 

Variance 

2.30 

7.  16 

7.70 

4.50 

7.  18 

6.30 

9.00 

<  xE-5) 

The  analysis  -for  determining  the  best  factor  levels  of 
factors  four  and  five  was  conducted  in  the  same  manner  as 
the  analysis  for  factors  one,  two,  and  three.  Table  B-15 
summarizes  the  results  of  the  analysis  for  performance 
measure  one.  Factor  level  two  has  the  highest  mean  (0.956) 
and  a  variance  of  7.16E-5.  The  degrees  of  freedom  for  all 
of  the  tests  performed  in  this  section  are  (9,9)  and  16  for 
the  F-test  and  the  T-test,  respectively.  The  results  show 
that  this  factor  level  is  better  than  all  other  factor 
levels  tested.  Setting  factor  four  at  0.2  and  factor  five 
at  0.8  achieves  the  best  results  for  performance  measure 


Table  B-15.  Results  -for  Factors  Four  and  Five 
■for  Per-f ormance  Measure  One 


Factor 

Mean 

Var i ance 

Computed 

Computed 

Level 

F-val ue 

T-val  ue 

1 

8.953 

2 . 30E-5 

3.  1 1 

-2.93 

3 

0.951 

7.70E-5 

1.08 

-13.88 

4 

0.943 

4.50E-5 

1.59 

-11.42 

5 

0.944 

7. 18E-5 

1.00 

-11.42 

6 

0.942 

6 . 30E-5 

1 .  14 

-9.51 

7 

0.943 

9.00E-5 

1.20 

-10 .45 

Table  B- 

14.  Resul ts  From 
and  Five  -for 

Data  Runs  for  Factors  Four 
Performance  Measure  Two 

Factors  4  and  5  Levels 


Factors 
1,2, and  3 
Level s 

1 

2 

3 

4 

5 

6 

7 

1 

0.94 

0.94 

0.94 

0.93 

0.93 

0.93 

0.93 

2 

0.94 

0.94 

0.93 

0.92 

0.92 

0.92 

0.91 

3 

0.93 

0.93 

0.93 

0.92 

0.92 

0.92 

0.92 

4 

0.92 

0.94 

0.94 

0.90 

0.90 

0.89 

0.89 

5 

0.90 

0.90 

0.90 

0.90 

0.89 

0.89 

0.88 

6 

0.91 

0.91 

0.91 

0.90 

0.90 

0.89 

0.89 

7 

0.91 

0.91 

0.90 

0.90 

0.89 

0.90 

0.89 

8 

0.90 

0.90 

0.89 

0.89 

0.88 

0.89 

0.88 

9 

0.90 

0.91 

0.89 

0.89 

0.88 

0.88 

0.87 

10 

0.90 

0.90 

0.89 

0.89 

0.89 

0.87 

0.88 

Mean 

.915 

.918 

.912 

.904 

.899 

.898 

.894 

Variance 
<  xE-4) 

2.70 

3. 10 

4.40 

2.04 

3.11 

3.70 

3.82 

l 

I 
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Factor  level  two  has  the  highest  mean  (0.918)  with  a 
variance  of  3.1E-4  for  performance  measure  two.  Factor 
levels  one  and  two  were  found  to  have  statistically  equi¬ 
valent  means.  Both  of  these  factor  levels  are  the  best 
factor  settings  for  factors  four  and  five  for  performance 
measure  two.  The  results  are  summarized  in  Table  B-17. 
Again,  the  degrees  of  freedom  are  (9,9)  and  18  for  the 
F-test  and  T-test  respectively  for  all  tests. 


Table  B-17.  Results  for  Factors  Four  and  Five 
for  Performance  Measure  Two 


Factor 

Mean 

Variance 

Computed 

Computed 

Level 

F-val ue 

T-val  ue 

1 

8.915 

2.70E-4 

1.15 

-1.18 

3 

0.912 

4.40E-4 

1.42 

-2.08 

4 

0.904 

2.04E-4 

1.52 

-5.86 

5 

0.899 

3.11E-4 

1.00 

-7.23 

6 

0.898 

3.70E-4 

1.19 

-7.28 

7 

0.894 

3.82E-4 

1.23 

-8.66 
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Table  B-18.  Results  From  Data  Runs  -for  Factors  Four 
and  Five  -for  Performance  Measure  Three 


Factors  4  and  5  Levels 


Factors 

1,2, and  3 

1 

2 

3 

4 

5 

6 

7 

Level s 

1 

0.95 

0.95 

0.94 

0.93 

0.93 

0.92 

0.91 

2 

0.94 

0.94 

0.93 

0.92 

0.91 

0.91 

0.91 

3 

0.94 

0.94 

0.92 

0.92 

0.91 

0.91 

0.91 

4 

8.91 

0.95 

0.94 

0.89 

0.89 

0.87 

0.87 

5 

0.89 

0.89 

0.89 

0.89 

0.88 

0.87 

0.86 

6 

0.90 

0.90 

0.90 

0.89 

0.89 

0.87 

0.87 

7 

0.90 

0.90 

0.89 

0.88 

0.88 

0.88 

0.87 

8 

0.89 

0.89 

0.88 

0.87 

0.86 

0.87 

0.85 

9 

0.89 

0.89 

0.88 

0.87 

0.86 

8.85 

0.84 

10 

8.88 

0.88 

0.87 

0.86 

0.86 

0.84 

0.85 

Mean 

.909 

.913 

.904 

.892 

.887 

.879 

.874 

Variance 

6.32 

8.00 

6.90 

5.70 

5.80 

7.00 

7.20 

<xE-4> 

Factor 

1  evel 

two  still 

has 

the  highest  mean 

i  <0.913)  w 

a  variance  of  8.00E-4.  A  summary  of  the  results  is  present¬ 
ed  in  Table  B-19.  Factor  levels  two  and  four  were  found  to 
be  the  best  factor  settings.  This  shows  that  factor  level  2 
(factor  four  set  to  0.2  and  factor  five  set  to  0.8)  is  the 
best  factor  setting  for  all  three  performance  measures. 


Table  B-19.  Results  -for  Factors  Four  and  Five 
■for  Performance  Measure  Three 


Fac  tor 

Mean 

Variance 

Computed 

Computed 

Level 

F-val  ue 

T-val ue 

1 

0.909 

6.32E-4 

1.27 

-1.00 

3 

0.904 

6.90E-4 

1.16 

-2.21 

4 

0.892 

5.70E-4 

1.40 

-5.38 

5 

0.887 

5.80E-4 

1.38 

-6.64 

6 

0.879 

7.00E-4 

1.14 

-8.33 

7 

0.874 

7.20E-4 

1.11 

-9.49 
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Data  Points 

FI  F2  F3 

Maximum  SCP 

PM  Value 

Minimum  SCP 

PM  Value 

e.e 

0.8 

0.0 

0.908 

0.910 

0.0 

0.8 

0.2 

0.920 

0.910 

0.1 

6.6 

0.1 

0.913 

0.915 

0.1 

0.6 

0.3 

0.930 

0.930 

0.1 

0.8 

0.1 

0.910 

0.915 

0.2 

0.4 

0.2 

0.920 

0.925 

0.2 

0.4 

0.4 

0.938 

0.940 

0.2 

0.6 

0.2 

0.925 

0.930 

0.2 

0.8 

0.0 

0.908 

0.910 

0.3 

0.3 

0.1 

0.918 

0.918 

0.3 

0.3 

0.3 

0.930 

0.930 

0.3 

0.5 

0.1 

0.918 

0.920 

0.3 

0.5 

0.2 

0.923 

0.925 

«D 

0) 

0.6 

0.1 

0.910 

0.948 

0.3 

0.7 

0.0 

0.910 

0.910 

0.4 

0.4 

0.2 

0.920 

0.926 

0.4 

0 . 6 

0.0 

0.910 

0.910 

0.5 

0.3 

0.1 

0.918 

0.923 

0.5 

0.3 

0.2 

0.920 

0.930 

0.5 

0.5 

0.0 

0.918 

0.913 

0.0 

1.0 

0.0 

0.908 

0.910 
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Table  B-21.  Performance  Measure  Values  for  Maximum 

versus  Minimum  SCP  Force  for  Performance 
Measure  Two 


Data  Points 

FI  F2  F3 

Maximum  SCP 

PM  Value 

Minimum  SCP 

PM  Value 

8.8 

0.8 

8.0 

0.828 

0.825 

0.0 

0.8 

0.2 

0.858 

8.858 

0.1 

0.6 

0.1 

0.838 

0.848 

0.1 

0.6 

0.3 

0.865 

0.878 

0.1 

0.8 

0.1 

8.832 

0.848 

0.2 

8.4 

0.2 

8.853 

8.860 

8.2 

0.4 

0.4 

0.885 

0.895 

8.2 

0.6 

0.2 

8.855 

0.868 

0.2 

8.8 

0.0 

0.813 

0.838 

8.3 

0.3 

0.1 

0.838 

0.845 

0.3 

0.3 

8.3 

0.868 

8.875 

0.3 

0.5 

0.1 

8.840 

0.850 

0.3 

0.5 

0.2 

8.855 

0.858 

0.3 

8.6 

0.1 

0.833 

0.912 

0.3 

0.7 

0.0 

0.830 

0 . 835 

0.4 

0.4 

8.2 

0.853 

0.865 

0.4 

0.6 

0.0 

0.828 

0.838 

0.5 

0.3 

0.1 

0.840 

0.858 

0.5 

0.3 

8.2 

0.852 

0.868 

0.5 

8.5 

0.0 

0.822 

0.838 

0.0 

1.0 

0.0 

0.825 

0.828 
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Table  B-22.  Performance  Measure  Ualues  for  Maximum 

versus  Minimum  SCP  Force  for  Performance 
Measure  Three 


Data  Points 

FI  F2  F3 

Maximum  SCP 

PM  Value 

Minimum  SCP 
PM  Value 

8.0 

0.8 

0.0 

0.770 

0.773 

0.0 

0.8 

0.2 

0.813 

0.820 

0.1 

0.6 

0.1 

0.715 

0.800 

0.1 

0.6 

0.3 

0.835 

0.848 

0.1 

0.8 

0.1 

0.793 

0.808 

0.2 

0.4 

0.2 

0.815 

0.828 

0.2 

0.4 

0.4 

0.865 

0.880 

0.2 

0.6 

0.2 

0.825 

0.830 

0.2 

0.8 

0.0 

0.765 

0.780 

0.3 

0.3 

0.1 

0.800 

0.808 

0.3 

8.3 

0.3 

0.838 

0.850 

0.3 

0.5 

0.1 

0.800 

0.813 

0.3 

0.5 

0.2 

0.825 

0.828 

0.3 

0.6 

0.1 

0.793 

0.888 

0.3 

0.7 

0.0 

0.778 

0.793 

0.4 

0.4 

0.2 

0.818 

8.833 

0.4 

0.6 

0.0 

0.788 

8.795 

0.5 

0.3 

0.1 

0.798 

8.818 

0.5 

0.3 

0.2 

0.818 

0.858 

0.5 

0.5 

0.0 

0.772 

0.788 

0.0 

1.0 

0.0 

0.773 

0.778 

.v^v^lVV.7. 


The  analysis  of  the  data  -for  a  maximum  SCP  -force  was 
conducted  in  the  same  manner  as  the  rest  o-f  the  resul  ts. 

The  results  are  summarized  in  Table  B-23.  The  degrees  o-f 
-freedom  used  in  the  table  are  <28,20)  and  48  -for  the  F-test 
and  T-test  respective! y .  The  results  show  that  the  minimum 
SCP  -force  has  a  better  mean  value  -for  all  three  performance 
measures. 


Table  B-23.  Results  o-f  Analysis  o-f  Maximum  versus 
Minimum  SCP  Force 


Performance 

Mean 

Variance  <xE-4) 

F 

T 

Measure 

Min  Max 

Min 

Max 

Val  ue 

Val  ue 

1 

.921  .918 

1.17 

.679 

1.72 

-4.52 

2 

.855  .843 

4.87 

3.  19 

1.53 

-8 .66 

3 

.828  .888 

18.2 

18.4 

1.02 

-9.07 

Table  B-24. 

Performance 

Measure 

Values 

for  Leave  versus 

Non-Leave  Schedules  -for  Performance 
Measure  One 


Data  Points 

Leave 

No  Leave 

FI 

F2 

F3 

PM  Value 

PM  Value 

0.2 

0.4 

0.2 

8.893 

8.925 

0.2 

0.4 

0.4 

0.908 

0.94O 

8.2 

9.6 

8.2 

0.898 

8.930 

0.3 

8.3 

0.1 

8.885 

0.918 

8.3 

0.3 

0.3 

0.905 

0.930 

0.3 

0.5 

8.1 

0.885 

0.920 

0.4 

8.4 

8.2 

0.898 

0.926 

8.4 

0.6 

0.8 

0.885 

0.910 

0.5 

0.3 

0.1 

0.888 

0.923 

0.5 

8.3 

0.2 

0.903 

0.930 

0.5 

0.5 

0.0 

0.863 

0.913 
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Table  8-25.  Performance  Measure  Values  for  Leave  versus 
Non-Leave  Schedules  for  Performance 
Measure  Two 


Data  Points 

Leave 

No  Leave 

Fi 

F2 

F3 

PM  Value 

PM  Value 

0.2 

0.4 

0.2 

0.830 

0.840 

8.2 

0.4 

0.4 

0.840 

0.895 

0.2 

0.4 

0.2 

0.835 

0.840 

0.3 

0.3 

0.1 

0.820 

0.845 

8.3 

0.3 

0.3 

0.850 

0.875 

6.3 

0.5 

0.1 

0.823 

0.850 

0.4 

0.4 

0.2 

0.838 

0.845 

0.4 

0.4 

0.0 

0.810 

0.838 

0.5 

0.3 

0.1 

0.820 

0.858 

0.5 

0.3 

0.2 

0.838 

0.848 

0.5 

0.5 

0.0 

0.793 

0.838 

Table  8-24.  Performance  Measure  Values  for  Leave  versus 
Non-Leave  Schedules  for  Performance 
Measure  Three 


Data  Points 

Leave 

No  Leave 

FI 

F2 

F3 

PM  Value 

PM  Value 

0.2 

0.4 

0.2 

0.790 

0.828 

0.2 

0.4 

0.4 

0.828 

0.880 

0.2 

0.4 

0.2 

0.790 

0.830 

0.3 

0.3 

0.1 

0.773 

0.808 

0.3 

0.3 

0.3 

0.813 

0.850 

0.3 

0.5 

0.1 

0.770 

0.813 

0.4 

0.4 

0.2 

0.803 

0.833 

0.4 

0.4 

0.0 

0.758 

0.795 

0.5 

0.3 

0.1 

0.770 

0.818 

0.5 

0.3 

0.2 

0.793 

0.858 

0.5 

0.5 

0.0 

0.745 

0.788 
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The  analysis  -for  inserting  an  assumed  leave  distribution 
into  the  scheduling  program  is  in  the  same  -format  as  the 
analysis  of  the  maximum  SCP  force.  The  degrees  of  freedom 
for  the  analysis  are  <10, 10)  and  20  for  the  F-test  and  the 
T-test,  respective! y .  The  results,  presented  in  Table  B-27, 
show  that  the  schedule  with  no  leave  distribution  has  a 
higher  average  performance  measure  value  than  a  schedule 
with  an  assumed  leave  distribution  for  all  three  performance 
measures . 


W-: 


Table  B-27.  Results  of  Analysis  of  Leave  vs. Non-Leave 
Schedul es 


Performance  Mean 

Variance  <xE-4> 

F 

T 

Measure  Lv 

No  Lv 

Lv 

No  Lv 

Val  ue 

Val  ue 

1  .892 

.924 

1.62 

.734 

2.21 

-21.87 

2  .829 

.859 

3.45 

2.83 

1.22 

-20.93 

3  .785 

.827 

5.99 

7.53 

1.26 

-11.98 
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